AndStatus@Mastodon is a user on mastodon.social. 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 @AndStatus@mastodon.social

@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.
@jackyalcine
Why one-to-one relation of Actor to Account is an edge case; from https://github.com/w3c/activitypub/issues/260
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 https://github.com/w3c/activitypub/issues/260
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 https://github.com/w3c/activitypub/issues/260
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...
@cwebber@octodon.social Thank you for reply to the #ActivityPub issue at https://github.com/w3c/activitypub/issues/260
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: https://www.w3.org/TR/activitypub/
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...
@mike@macgirvin.com I agree that #ActivityStreams2 is well designed. Maybe this is exactly because its ideas are actively tested in practice for several years in pump.io. 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: https://github.com/w3c/activitypub/issues/260
Not many responses so far :-(
@zoowar This is exactly what I propose in this #ActivityPub specification bug report: https://github.com/w3c/activitypub/issues/260
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 https://www.w3.org/TR/activitypub has a gap/confusion of two different notions: Person (one of Actor types, see https://www.w3.org/TR/activitystreams-vocabulary/#dfn-person ) 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.
?!
@clacke

@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 ( https://nu.federati.net/ ), 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: https://github.com/andstatus/andstatus/wiki/FAQ
The change log lists features, added during the last six years, with links to detailed descriptions in corresponding development tickets: http://andstatus.org/changelog.html
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?
... https://loadaverage.org/attachment/3744263
@fuzboleroxv I think that Pump.io 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.
Pump.io 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.

#Mastodon
#challenges
#strategy
#performance
#credibility

@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 Pump.io 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 Pump.io 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 https://quitter.no/attachment/1390823
@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 @andstatus@quitter.no @andstatus@identi.ca @andstatus1@twitter.com ...

@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 ?