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.


While helping one of my friends to make UI of his application more responsive, I found out that #AndStatus needs similar fixes also... As a result of this discovery potentially long file access operations (actually, all file access functions) where moved to asynchronous tasks. And timeline scrolling became smooth!
Please try v.36.09 (currently in beta )
Currently I'm refactoring User-related part of #AndStatus data model using recent amendments of #ActivityPub specification, which I initiated: distinction between a User (a real life person or an organisation...), Accounts of this user in concrete instances (Servers) of the global social network, and an Actor - the entity, which is actually present in Activities of the ActivityPub protocol.
Very helpful clarifications, allowing me to express clearly relations between different things inside the application. For example, now I'm working towards creation of views on a User across all networks, logically merging Actors of this User.
As a result, at the first step you will see e.g. actions/messages by Actor as actions by ONE Actor, even if you see these actions via several Servers, e.g. via and via, as on the attached screenshot.
The next step will be to merge Actors of one User into one view. E.g. set and Actors as _one_ User. This cannot be done automatically due to current limitation of the #ActivityPub specification, but at least can be done manually for selected Users that you follow via their Actors in different networks...

tip: In order to "follow" any word or a hashtag, I Search for it in Everything timeline (Search timeline opens), and then make that "Search somehashtag" timeline automatically syncable in "Manage timelines". See how I "subscribed" to "AndStatus" in all social networks

...Yes, really. allows you to forget about Twitter, Mastodon, GNU Social and your accounts in their instances. And focus on content and users. I plan to merge a view on different segments of this global network even more...
On the other hand, you always see a channel, via which any concrete message was received. Your accounts on different servers _are_ that channels.

v.36.05 released to Production four days ago, it's available at Google Play and is expected at F-Droid...
v.36.06 is in Beta now with a fix for posted message editing (supported by Pump.lo only) and several permissions removed that aren't needed for modern Android.

Just installed the latest #AndStatus beta, it's improved infinitely since I last used it!
#AndStatus v.36.04 beta "Activities instead of messages, and enhancements of Notifications" is published at an Open Beta testing channel, see
In this beta release:
1. Translations for 6 new languages added and several existing updated. Many thanks to all volunteer translators making this work at BTW it's not too late to complete what's not done yet, please check that site.
2. Fixed a crash in Android 8, when syncing occurred in a background. This was the only problem reported during previous two weeks of beta testing, which confirms my observations that AndStatus is close to be released.
Please report any new major problems to be fixed before a release to the wider audience to
@hier So far no security updates of #AndStatus itself were ever needed. All security-related changes were caused by changes at a server side, which required network protocol changes for client applications including AndStatus.
I don't think similar protocol changes will be implemented in older versions of AndStatus.
What you may really need are security updates for Android firmware on your device.
#AndStatus v.36.02 Beta 2 published with updated translations
See Notifications settings on the attached screenshot
In #AndStatus v.36 in addition to a number of new events (activities/messages), notifications now show an Account (in a case a notification is for one account only) and time, when the last event occurred.
@hier Current version of #AndStatus is 35.06, and it can be used for Android devices v.4.4+ as long as you need.
Next version will be for newer devices/firmware, and this is natural cause of software evolution.
Sadly, but I also had to buy new tablet for myself in order to use newer applications...
@silverwizard wrote: "AndStatus is an Android app for OStatus clients"
This is wrong. #OStatus is a server-to-server protocol, #AndStatus connects to servers using server-to-client protocols. This is why AndStatus doesn't know and doesn't depend on OStatus protocol.
Moreover, #Mastodon 's client-to-server protocol is still based on outdated Twitter like API, not on #ActivityPub, unfortunately.
Why one-to-one relation of Actor to Account is an edge case; from
Actor is actually User's virtual identity, their identifiable representative in a social network. Now please think about the Global Social Network ("federation of websites”), which is connected using #ActivityPub protocol.
How many different Actors would you use and how many Accounts?
I mostly use two different actors: "yvolk" as my personal Actor, and "#AndStatus” as my project's Actor. But I use (or used recently, so there is a history of my posts...) tens of Accounts to represent these two logical Actors at different Servers (websites). And I don't expect to switch to two Accounts for these two Actors any time soon. For many reasons... And as I see posts of other Users, they quite often use several Accounts e.g. for wider audience (different Servers have different audiences and different posts are visible from them...) and as a backup in a case of a server's outage or permanent shut down.
Due to limitation of most of existing Servers, each separate Account means a separate Actor (and ActivityPub copies this approach). But this is not what a User wants, when he or she creates the same ”MyCoolUserName" at different Servers. Ideally a User needs to decide if any new Account is for the same existing Actor or for a new one.
#ActivityPub currently not only doesn't give such an option. It confuses terminology and mixes User/Account/Actor notions so, that it's even impossible to express the need and clearly state current limitation of the protocol using terminology of this spec. But it will allow to clarify this using changes, resulted from this our discussion ;-)
And I see that a User who needs only one Account for his Actor, is usually a Newbie or someone, who doesn't use a Social Network actively. This is why I regard one-to-one Account to Actor relation as an edge case, not as a normal one.
More on fixing #ActivityPub spec from
I understand that making "data model" correct by separating concerns would mean changes in the protocol specification, and I can understand eagerness of people, preparing the spec for a long time, to release it, at last, even not perfect. This is why I think that the most important thing now is to communicate clear and correct domain model and terminology, opening a way for future protocol improvements.
This means that decision on whether or not to fix the data model now shouldn't be anchored with changes, related to resolution of this issue #260.
E.g. despite still having "inbox URL" inside Actor object in a "data model" we should describe the URL as Account's attribute...
I continue my discussion with a team, creating #ActivityPub specification, doing my best to solve its conceptual mistake of presenting Users of the real world, their Accounts at servers and Actors of #ActivityStreams as synonyms, see
From that discussion:
Account is not an Actor, it's an authorised communication channel, a way for an Actor to communicate in a Social Network using a Server... (more work on this phrase may be needed but the meaning is this). And this relation should be stated in the main part of the document, not in some "notes", exactly because this is a conceptual level statement, not an implementation intricacy...
At the edge case, which happens to be the only case currently covered by the ActivityPub spec, Actor relates to Account as one-to-one. And only for that edge case mixing attributes of Actor and of Account can be done, but only as a temporary hack, violating design patterns... 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