AndStatus@Mastodon is a user on You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

AndStatus@Mastodon Thank you for reply to the #ActivityPub issue at
I followed the discussion there plus copying my follow-up below:
1. Let's go step by step. Explicitly stating that Actors and Users are different entities is a good way forward.
BTW the confusing phrase "users are represented as "actors" here" should also be changed to "users are mapped to actors" with addition, how (you suggested wording...)
Where can we see current draft for review how it looks now? You are too quick to state that the issue is resolved :-)
2. Let's check if the statement is valid:
* ""user" is technically an entity outside the protocol"
2.1 First of all the term is used tens times in the document, which describes the protocol:
2.2. The term "user" is used for two different things, actually:
* for "natural person from a real world"
* and for "user's account at a Servetr" (my interpretation).
The second meaning is definitely "inside protocol". Just look at these phrases, from many available, for example:
* "This protocol permits a client to act on behalf of a user."
* "Client to server interaction takes place through clients posting Activities to a user's outbox"
My conclusion is that a User in the second meaning "user's account at a Server" is definitely a part of the protocol description.
3. As now we agreed on separation of an Actor from a User, let's look again, what we read in the document.
3.1 You know: there are many places, where the word user(s) should be replaced with a word Actor(s), e.g. here {again, one of many examples):
* "The Follow activity is used to subscribe to the activities of another user."
Attributes of a User are presented as attributes of an Actor in examples... I agree that #ActivityStreams2 is well designed. Maybe this is exactly because its ideas are actively tested in practice for several years in Confusion of Actors and Users of servers in the #ActivityPub I regard as a conceptual mistake that should be fixed _now_. So I proposed concrete additions to the spec in this issue:
Not many responses so far :-(
@zoowar This is exactly what I propose in this #ActivityPub specification bug report:
Separation of Actors (e.g. a Person) from Users of servers (user accounts) even on a conceptual (domain model level). Please support this fix!
@mike @cwebber
@cwebber Reposting to make sure you received my reply. Where should I file this #ActivityPub issue?
The #ActivityPub spec's problem is not in that simplistic phrase "users are represented as actors here".
The problem is that there is NO technical description of the whole domain model layer: relation between Actors (e.g. Person) and Users of servers. Current version will be interpreted as having one-to-one relation between the two _different_ kinds of entities, and that _is_ incorrect
My first post on this subject was:
Contemplating on correct implementation of a data model, corresponding to the #ActivityPub specification, I started to realize that current version of the document has a gap/confusion of two different notions: Person (one of Actor types, see ) and a User of a server (quote from ActivityPub spec: "users are represented as "actors" here")
Actually these are very different notions: a Person may be represented as more than one User, on different servers. And a User may represent not a Person, but e.g. an Organization.

@cwebber The spec's problem is not in that simplistic phrase "users are represented as actors here".
The problem is that there is NO technical description of the whole domain model layer: relation between Actors (e.g. Person) and Users of servers. Current version will be interpreted as having one-to-one relation between the two _different_ kinds of entities, and that _is_ incorrect

@freyo There are some serious issues with #federation everywhere, including here. We should expect some breakage on a dev site, such as this one. I've been trying to help solve some of the general GS federation issues, but success has been very limited.

NFN, the main instance I host ( ), stopped receiving incoming posts from many (but not all) users on Highland Arrow and from *all* users on LoadAverage. My account on LA only receives posts from my NFN account if I directly mention someone on #LoadAverage. And, yes, this account rarely receives posts from off-site anymore. 

I have an account on the Mastodon developer's central instance, where I never know whether any contact's post will show up in the timeline.
@itsumonotakumi First of all, #AndStatus has FAQ, which allows to search for answers and to ask new questions:
The change log lists features, added during the last six years, with links to detailed descriptions in corresponding development tickets:
Regarding concrete features, which are marked as missed. Just from the top of my mind:
1. Drafts: You can "Save draft" during editing (see a diskette icon above with this tooltip). Plus, AndStatus has "Drafts timeline" whist lists all drafts chronologically like in any email application. Any draft can be edited or discarded, naturally.
How this could be overlooked, if you specifically searched for this feature?
2. Timeline filters. There is more than one way to have filtered timeline:
2.1 Search for one or several words. Resulted filtered timeline can be even made syncable! (see Manage timelines menu item)
2.2. See "Filters" section in Settings.
Do you think that an interested User won't notice any of these ways to filter a Timeline?
@fuzboleroxv I think that solved the problem with non-synchronized remote User's info/messages the best: instead of loading network with synchronization of questionable importance, its API allows client application to go directly to the User's instance and grab any interesting (publicly available) data from the "golden source". This approach guarantees that you will see all User's public posts etc. clients, including #AndStatus, can do this for years, because this is natural and simple ;-)
@vavassor @gargron

2/2. The #concept of "following", as implemented on various #socialMedia #platforms, needs a global rethink anyway, and as such is currently "up for grabs" for a potential #MastodonStrategy.

As for the counter issues; Each instance should know whenever it's count is out of sync and offer the possibility to update directly from the origin.

Maybe there is a need to finance a network of hub servers to provide all instances with fast up-to-date indexes?

Even with legitimate and logical reasons behind the mismatching #synchronization, that is not a situation that will help this platform succeed.


@Vavassor @tschneider
@thor @AndStatus @Gargron

@andstatus @thefaico Your proposed rebuild of AndStatus will more than make up for anything that I felt was lacking in and would encourage me to start using again. Your work and dedication to Andstatus is as admirable as ever, thank you!

@raizel Which concrete feature are you missing?
Currently I'm rebuilding #AndStatus to support #ActivityStreams as a data model natively. In particular, Notifications / Activities timeline will be introduced to show all incoming Activities (and not messages only as now) in the order they were actually received by this device (and not in the order of dates, when corresponding messages were published or actions occurred). So users (especially having multiple accounts) won't wonder, for example, which "New mentions" were received.
This will immediately make AndStatus much more friendlier to existing users, I think.
I decided to drop support of Android versions before v.5.0 in the future releases of #AndStatus
This will allow to start cleaning code from outdated solutions and components...
Android v.4 devices currently amount to less than 13% of active devices, which have AndStatus installed, according to Google Play statistics.
@1iceloops123 You can change default timeline in "Manage Timelines" -> "Set as Default Timeline" context menu item
@1iceloops123 "critique" is far better for the project and for developer's inspiration than silent uninstall :-)
For #AndStatus news and tips please follow one of my accounts (the list and order of accounts changes over time...):
@andstatus @andstatus ...

@tschneider @Gargron @AndStatus -

There seem to be problems with showing full threads.(?)

I cannot see the reply I reply to here now from my @LeeteqXV user.

Often if I open a reply and expect to get access to the full thread, I can only see some of its replies. When I back out, find the timeline of the user that posted the initial toot, find and open that toot, only then can I see the whole thread. #Mastodon #Bug ?

@infO_Overlord I think this is why e.g. Oracle Database doesn't have an embedded mode: it doesn't want to show that it's too heavy, overloaded with unneeded options and slow for usage e.g. in Android or in automated testing...
@FuzboleroXV @LeeteqXV

Suggested correction to
1. I noticed an inaccuracy in section 6.9. "Undo Activity"
"The undo activity and the activity being undone must both have the same author."
"author" should be changed to "actor" here so it will read:
"The undo activity and the activity being undone must both have the same actor."
2. Actually, the "author" property is used (informally ?!) in examples of this document, but I didn't find _any_ reference to such a "property" in
the latter documents uses "actor" instead.
Looks like autor should be replaced with "actor" in examples also to avoid confusion and incompatible implementations...

 In order to foster F-Droid support of Beta releases, I posted my vision of the target process to the relevant F-Droid's change ticket, see:

@Gargron Is this post an recommended example of breaking 500-characters limit in ? ;-)
(notorious hack for Twitter BTW)