Relation between Actors and Users of servers is undefined

[yvolk]

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.

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

[yvolk]

This bug is exactly about Person's freedom to choose (and actually, change) an instance/server of a global social network without loosing his/her identity, including historical data. Moving from one instance of a federation to another is a normal case, just like having user accounts at several servers. And #ActivityPub specification should explicitly allow this.

[nightpool]

I don't think there's ANY normative concept of a server OR a user in the current activitypub spec? Can you point to a section that defines these things?

While your concern is well-taken, I don't think it makes a lot of sense to frame it in this way. Actors have inbox_urls and outbox_urls, they may exist on the same server that authenticates them, or they may not. It's entirely up to the implementation

On Fri, Sep 29, 2017 at 3:21 AM Yuri Volkov notifications@github.com wrote:

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.

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/260, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV26ileWk61tE01OaRJGXimbLGRB8ks5snJqFgaJpZM4PoShQ .

[yvolk]

@nightpool Yes, this issue is about absence of any normative concept about relation of a User to an Actor. And I think that this gap will cause implementations, which will allow neither having multiple User accounts for one Actor on different servers nor (in particular) moving one Person's account between federation instances without losing his/her identity, including historical data.

My view is that these features now become key features of a federated social network, when people are searching for better places for their social identities, when servers are being constantly created and shut down...

[cwebber]

@yvolk Not describing users in relation to actors is intentional, since actors may be many types of entities. And yes, a "user" (as in a person) could have multiple actors.

And I think that this gap will cause implementations, which will allow neither having multiple User accounts for one Actor on different servers nor (in particular) moving one Person's account between federation instances without losing his/her identity, including historical data.

My view is that these features now become key features of a federated social network, when people are searching for better places for their social identities, when servers are being constantly created and shut down...

Ah okay, we're back to nomadic identity again :) Perhaps this is the real root of your issue, that users can't migrate between servers easily in a basic implementation of ActivityPub?

In fact we have had a lot of conversation about account migration / nomadic identity on the SocialCG issue tracker. I also have also written a paper that describes how users may have more self-sovereign identity using DIDs. Perhaps this issue is what you are primarily concerned with here?

[yvolk]

@cwebber Thank you for the links. Discussion on "Follower migration" is very informative and is also about Persons' identities and GUIDs and Person to a User relation. In your document on "ActivityPub: from decentralized to distributed social networks" you make the same mistake to prevent which I created this ticket: actually putting "equals" sign between a Person and a User ( "...By attaching public keys to the profiles of actors (users) on the network..") :-( although you agree with multiple users to a Person relation here.

In order to ensure easier future improvents of #ActivityPub implementations the spec should clearly state this:

1. A User is an authorised communication channel, a way for an Actor to communicate in a Social Network.
2. ‎An Actor HAS Users. Current specification doesn't define a way to associate more than one User to an Actor... (but in the data model we can say that an Actor has Users collection of User objects...)
3. ‎Actor e.g. Person has a GUID, separate from GUIDs of its Users. This is an Actor, who is a recipient of messages , who is Followed etc. by other Actors (this is written in ActivityStreams spec already), and this is a User (preferred User in a case of more than one user), whose attributes (URLs...) are used for messages delivery.

You see: a Person doesn't have any "inbox" etc., but a User has!

Now we don't know (didn't decide yet) how to globally implement multiple Users for an Actor in a reliable and secure enough way, but such implementations could be easily created for private/client's solutions. E.g. in a Client application the application's user may decide for himself/herself that some two Users are actually Users of one Person and thus have a fuller profile of that person, being able to preserve the whole history/identity of that Person, when that Person starts posting from another host via another User...

[cwebber]

There are multiple issues being conflated here:

• One source of confusion is that the confusion here is that a "user" is technically an entity outside the protocol, and an "Actor" is the actual entity being piloted within the system. There is no need to model the user because the user isn't in the system. In fact Actors can be piloted by non-"users", in the sense that they can also be piloted by some program run on the server. So -1 on adding new terminology describing Users... they aren't in the system, and that's intentional.
• If we want to describe different profiles being sub-identities of an Actor, we can use the Profile type, which I think may satisfy some of your concerns.
• The other bit is allowing users to move between servers, and this is tricky because you may either generate a new separate actor or actually have the actor itself migrated between systems depending on the approach taken. But I think the decisions on how to do that are out of scope for this spec at this time, and should be taken to the Social Community Group (and that's already happening).

I agree that the describing actors as users is a bit of a conflation, and that bit should be cleaned up.

[cwebber]

<eprodrom> RESOLVED: Resolve https://github.com/w3c/activitypub/issues/260 by                      
           clarifying that there is no specific mapping of one user to one                         
           actor (and there can be many configurations) in the spec; leave                         
           follower migration to SocialCG, and do not add extra modeling of                        
           mapping real-world Users to Actors

[yvolk]

@cwebber Thank you for reply.

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 the real world"
• and for "user's account at a Server" (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.

4. Attributes of a User are presented as attributes of an Actor in examples...

[strugee]

Where can we see current draft for review how it looks now?

https://w3c.github.io/activitypub/

You are too quick to state that the issue is resolved :-)

@cwebber meant that the Working Group had voted on a resolution to this issue, not that it had been resolved in-text :)

[yvolk]

@cwebber meant that the Working Group had voted on a resolution to this issue, not that it had been resolved in-text :)

@strugee Reading my previous comment, I hope, you see that the issue is far from being resolved?!

[yvolk]

@cwebber @strugee Pals, let's not stop at the first step, leaving the spec full of inconsistencies, related to this bug!

If you don't have resources for this work, I could do these changes/fixes myself, step-by-step as for a Code Review :-) ?!

[strugee]

@strugee Reading my previous comment, I hope, you see that the issue is far from being resolved?!

Sorry, I think you're misunderstanding what I'm saying. When I said "the Working Group has voted on a resolution to this issue," I meant that we had voted on how we want to proceed here (that was what @cwebber was quoting). However, that doesn't mean the plan has actually been carried out in the text, which is why this issue is still marked as "open" on GitHub and which is why you don't see any changes.

[strugee]

So in other words, you're correct that there are still problems in the text, and we'll make sure to address them. It's just that no one's gotten around to it yet.

(I also believe we can't accept PRs from outside of the Working Group but I'm not sure since we've been more lax recently... @sandhawke and/or @cwebber?)

[sandhawke]

We can accept PR's if someone's willing to put an ink signature on paper and send it physically to our offices at MIT. If that's the plan, I can dig up the form.

[yvolk]

@strugee @sandhawke Thank you for clarifications, your words made me much more optimistic. I understand that finding bugs in somebody's work is easier than fixing them :-) Regarding taking part in specifications' refinements, first time I did this for W3C RDF draft almost 20 years ago... @sandhawke I assume that the form you referring to is not for a single PR?! If yes, I think that I have to do this: please send me the form.

[sandhawke]

The paperwork is here: https://www.w3.org/2004/01/pp-impl/35520/nmlc

The staff is aware of how absurd this is for a PR, and is developing a much lighter weight solution, but it's not ready yet.

[strugee]

@yvolk if you want to go through the hassle then by all means go ahead, but you could also have wait for us to take care of it. You might also want to double-check with @cwebber that your changes will be accepted.

[sandhawke]

Meanwhile, it turns out I was wrong -- we can accept PRs as long as they re "non-substantive" (that is, they don't actually change what implementations have to do).

[yvolk]

@sandhawke Good, thank you for the clarification. In my notes on what's mixed/confused and needs to be changed (see https://github.com/w3c/activitypub/issues/260#issuecomment-336027427 ) points 1- 3 are just Editorial and only point 4 could lead to changes in implementation: "Attributes of a User are presented as attributes of an Actor in examples..." But we can think about that part later. Step-by-step ;-)

[yvolk]

@cwebber @sandhawke @strugee I cloned the spec's repository and reviewed changes done to origin/gh-pages branch since I raised the issue. I didn't find any changes, related to this issue yet (still cannot understand "RESOLVED:" in https://github.com/w3c/activitypub/issues/260#issuecomment-335551889 ), but found two typos. I think that separation of changes on different topics would be good, so may I create my first PR with just two typos fixed?! ... done https://github.com/w3c/activitypub/pull/263

[rhiaro]

Hi @yvolk, "RESOLVED" means that the WG agreed that we will make a change according to the issue you raised. It means we reached a resolution to do something regarding this issue. It doesn't mean the issue itself is resolved. Basically.. we resolved to resolve it :)

On that note, I'm aiming to updated the wording by the end of this week at the latest in an attempt to resolve the issue itself in a way you are satisfied with. Unless you beat me to it! But stay tuned.

[rhiaro]

By the way @yvolk I agree absolutely with your perspective on making sure implementations don't think they must restrict people to one account or one person per account etc. But I also think that most people who are implementing the spec at the moment (which is a small number of people who are largely in the loop of the WG's current conversations) agree too.. and actually won't interpret it in the way that you are concerned about.

But it's great that you raised it, because it gives us chance to clarify in time for the spec to reach a wider and more diverse audience who may not share the same worldview on this as the rest of us. But I don't think implementations will be affected as things stand presently. (The point I'm making is that I'm confident this is an editorial clarification, rather than an normative change; we meant it this way all along).

[yvolk]

@rhiaro I also started to make changes, and I think that as a first step I will make changes to the "Overview" section only, because actually this section informally defines the most important terms and relations between them. After fixing this section, it will be much more evident, how to fix others. After reading carefully above discussion I see that in order to solve current terminology problem, we need to introduce another term (and corresponding entity): Account as user's account at a server. So the term user will mean "User from the real world" only. So we will actually carefully change usages of the two words: "user" and "actor" to the three words: "user", "actor" and "account"... ?!

[rhiaro]

@yvolk Respectfully, I think introducing a third term might complicate things further.

Actor is the only term formally in the vocabulary (ActivityStreams 2.0). Use of "user" in the spec is more of a colloquialism.

My update would be to add a sentence or two in the overview to clarify that in practical terms Actor refers to refers to the operator(s) of an account on a server. Behind an Actor we may find one or more human beings, a legal entity, a collective or other organisation of some kind. Similarly, any individual human being or collective may operate multiple accounts across any number of servers, thus serving as more than one Actor as far as the protocol is concerned.

Then we should remove all references to "user" in the spec and replace with the formal term Actor where it fits, to reduce the ambiguity as far as possible.

Things the protocol does not cover (and that I do not think we need to mention explicitly):

• Policies of particular implementations with regards to whether people are allowed to create more than one account, etc.
• Mapping between multiple Actors which happen to have the same human being behind them. I could see servers implementing this, but it is outside of the scope of the protocol at this time.

[rhiaro]

@yvolk I'd like to add that ActivityPub's goal is not to make a complete model of the possible ways people can interact with social system. The vocabulary and terminology AP uses comes from the ActivityStreams 2.0 standard, which was finished a while back. The goal of AP is to define some clearcut ways in which Activities (per the ActivityStreams 2.0 vocab) can be passed around a network.

Actor is deliberately the bare minimum needed to link an account in a system with an action carried out by that account.

Implementations which need more complex models of their users are welcome of course to extend the core vocabulary with their own terms. And different systems are likely to want to do so in different ways. Keeping AP simple and neutral in this respect means it'll be (hopefully) useful to a wider variety of systems as a core for them to build upon and specialise. We don't want to over-specify the data model here, because we may unwittingly exclude implementations for whom this does not fit.

[yvolk]

The vocabulary and terminology AP uses comes from the ActivityStreams 2.0 standard, which was finished a while back

@rhiaro Did you forget about the term Server that AP introduces and that is not present in ActivityStreams vocabulary?! Account is a "glue" between Users of the real world, Servers of ActivityPub and Actors of ActivityStreams. Avoidance of such a glue has led us to the confusion, which we are now struggling to resolve. This is why introduction of Account (or similar term) is not a complication but a clarification of relations between these terms.

Server and Account are at another layer, not covered by ActivityStreams: this is communication/transport... layer. And as I currently see, these two terms can allow to keep this additional layer clean and simple. For example, they can allow to avoid mixing attributes of the communication layer into entities of ActivityStreams.

[rhiaro]

"Server" is not part of the formal protocol vocabulary, or the data model.

I'm now not sure whether you're suggesting adding "Account" to the data model, or simply using the word in places of / alongside "user". We can't add new terms to the data model at this point (that would be normative) but we can change the language we use in the specification.

I see your use of "Account" as interchangeable with Actor (from the data model) in a practical sense.

We don't need to model real-world users, because the protocol doesn't extend beyond moving Activities (blobs of AS2 JSON) around. We're not modelling the 'real world' or the offline world. The protocol itself doesn't care that the real world exists at all. Implementations sure do, but not the protocol.

Thus, we can clarify these terms as a note for implementors, but we don't need to explicitly define extra terms in the protocol.

Does that make sense?

[yvolk]

1. My previous comment introducing Account, describes the system's landscape at a level the "Overview" section does: at that point of view we talk about domain model and no normative "data model" exists. This is why I think the Overview section should clearly and briefly introduce Server, User, Account and Actor terms and relations between them.

2. 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...

3. 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...

4. We don't need to model real-world users

My view as an architect is that we do model real world users even in "textual" descriptions of the document and "examples", even in the Overview. This is why sometimes words around "normative statements" mean and weight more than that formal statements...

[rhiaro]

I'm afraid I don't understand what we gain in this case by treating Account and Actor as separate things which we didn't already have. Nor do I follow why the one-to-one is an edge case.

As was mentioned earlier in this thread, if one needs to differentiate one can already use Profile from AS2.

Re 4. I cede your point that the descriptive text is important. To some extent we need to describe a likely real world scenario so the reader understands what we're talking about. I just meant we don't need such distinctions in the data model itself.

I still don't think that your initial reading whereby the reader jumps to the conclusion that the protocol makes it impossible for there to be anything other than a one-to-one ratio of humans to accounts is the most likely reading though. Certainly as nobody writing the protocol ever intended that.

[yvolk]

I still don't think that your initial reading whereby the reader jumps to the conclusion that the protocol makes it impossible for there to be anything other than a one-to-one ratio of humans to accounts is the most likely reading though. Certainly as nobody writing the protocol ever intended that.

Using the Account term, I can now clarify that Current version of the spec will be read as Account to Actor not only having one-to-one relation, but that they are the same entity. But as current draft doesn't even have Account notion yet, the relation is even more misty...

This is an example of a gain from having clear Account term in the spec: we can express what we are talking about :-)

2. Why one-to-one relation of Actor to Account is an edge case. 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, or someone actively hiding their identity (e.g. a spammer)... This is why I regard one-to-one Account to Actor relation as an edge case, not as a normal one.

[rhiaro]

Okay, perhaps then it's worth replacing the use of "users" in the spec with "accounts", along with the note that the spec does not expect implementations to constrain the people-to-accounts ratio in any way.

ActivityPub currently not only doesn't give such an option

It doesn't prevent such an option either. It's up to implementations to enforce or not how many accounts people can have, and how many people can operate a single account. I think formalising that is out of scope for the protocol itself.

Discussion of protocols and practices for moving/migrating accounts between servers etc though is definitely happening in the CG.

[cwebber]

I just pushed 49b060c which does the following:

• Avoids conflating actors and users. The only point at which "user" is mentioned now is within some non-normative text which describes someone piloting a client, which I believe is still valid. All other examples were switched to "actor" or otherwise restructured.
• Adds a note clarifying that the spec does not specify any configuration of humans/organizations as users to accounts.

On that note, I think this is as good as we can do within ActivityPub itself. One reason for this is that the SocialWG already had a prior resolution that ActivityPub will not introduce vocabulary that does not affect the behavior of the protocol. If we want to discuss something like Account that's more than welcome in the SocialCG (though I'd note that we'd want to be sure that Profile does not already cover the use case)

Between those two things (committed spec-text and bringing other vocab extensions to the SocialCG) I hope this is good enough?

[yvolk]

Okay, perhaps then it's worth replacing the use of "users" in the spec with "accounts", along with the note that the spec does not expect implementations to constrain the people-to-accounts ratio in any way.

1. @rhiaro I feel that I couldn't communicate to you, where the problem is, yet. :-( One more time: 1.1. There is no problem in User-to-Account ("people-to-accounts" in your phrase) ratio where the term User means a natural person or an organization of the real world. 1.2. There is a problem in Account-to-Actor ratio being one-to-one in current version of the spec!

ActivityPub currently not only doesn't give such an option

It doesn't prevent such an option either. It's up to implementations to enforce or not how many accounts people can have, and how many people can operate a single account. I think formalising that is out of scope for the protocol itself.

I wrote neither about "how many accounts people can have" nor about "how many people can operate a single account", so you touch another topic here... The specification prevents an option to have more than one Account for one Actor, not for a User! Please read my previous note "Why one-to-one relation of Actor to Account is an edge case", where I give my own example of 1 User, 2 Actors and tens Accounts (i.e. more than one Account per an Actor :-) ).

[yvolk]

Between those two things (committed spec-text and bringing other vocab extensions to the SocialCG) I hope this is good enough?

@cwebber No :-) Thank you for making these changes, but we're not done yet.

1. We still didn't address "one account for one actor" problem. Please see my previous comment, it fully applies to your previous post and to your changes in the commit
2. I suggested another wording for your change in the Overview, please see my comment there.
3. There are more places, where the user/users term needs a change... But I don't want us to lose focus now and I suggest not to rush making changes to the whole document (without PR and a review... ?!), but concentrate on clarifying / agreeing on User/Account/Actor terms in the Overview first. Please.

If we want to discuss something like Account that's more than welcome in the SocialCG (though I'd note that we'd want to be sure that Profile does not already cover the use case)

Account is exactly the term needed for this document. And I explained in this comment, why. As I wrote above, Account and Server are notions of a communication / transport layer of the domain model, this is not an "ActivityStreams" layer, where the Profile term is defined. This means that Profile may (or may not...) be used to implement Account notion in the ActivityPub's data model, but it cannot "cover" Account, because they are at different levels of abstraction. Do you see the difference?

[rhiaro]

You're right this protocol does not cover the one-Actor-two-accounts use case. That's because as far as the protocol is concerned, an actor is equivalent to an account (which you agreed here).

The protocol needs to know, starting from the URI of an Actor, how to route messages.

An Actor is represented by one URI. Messages are delivered to the inbox of an Actor and each Actor can only have one inbox, and similarly clients look for the logged in Actor's outbox in order to post updates. If an Actor suddenly has two "accounts", does this mean it then has two URIs? Should a sending server or client dereference both of these to look for inbox/outbox? Basically AP starts at the point of having already decided which URI is being addressed/posted from. If, going in the other direction, there are two users behind that, that's fine and implementations can specify how that works themselves (as a formal extension to AP if desired). AP is the very core of getting messages delivered, that's all. So nothing is mapped or defined outside of what the protocol needs to do this.

Have you ever used TweetDeck? You can sign in with multiple twitter accounts, and choose which one you post to, or look at messages from. This isn't part of Twitter's internal delivery mechanism though. It's a layer on top. TweetDeck (the implementation) links these accounts together, but Twitter's protocol itself doesn't care, or need to, to route messages.

[yvolk]

You're right this protocol does not cover the one-Actor-two-accounts use case. That's because as far as the protocol is concerned, an actor is equivalent to an account (which you agreed here).

Hooray, now we both understand this protocol limitation using the same terminology! This is what I am trying to express since my first post a month ago.

If an Actor suddenly has two "accounts", does this mean it then has two URIs? Should a sending server or client dereference both of these to look for inbox/outbox? Basically AP starts at the point of having already decided which URI is being addressed/posted from. If, going in the other direction, there are two users behind that...

You are still confusing a User with an Account. Here should be "there are two Accounts behind that". Both accounts, belonging to a single Actor, usually will be owned by the same one User (unless maybe the Actor is some Organization ("group Actor") like e.g. "SiteAdmin" actor, where several people, working as admins of the same site, are posting messages as the same Actor but using their own Accounts...)

Regarding your questions on how should the protocol deal with more than one Account per an Actor (and hence how to deal with two URLs of Inbox etc.), I'm repeating here what I wrote earlier. Now using Account notion:

At the time of writing this specification we don't know (didn't decide yet on) how to globally implement multiple Accounts for an Actor in a reliable and secure enough way, but such implementations could be easily created for private/client's solutions. E.g. in a Client application the application's User may decide for himself/herself that some two Accounts are actually Accounts of one User (Person of the real world) and thus have a fuller profile of that person, being able to preserve the whole history/identity of that Person, when that Person starts posting from another host via another Account...

Have you ever used TweetDeck? You can sign in with multiple twitter accounts, and choose which one you post to, or look at messages from...

AndStatus application, which I'm developing for the last 8 years, allows a User to Act as any of Accounts of the same Social Network since October 2013 (as I see in the ChangeLog). And it can do this now for all supported systems including Twitter, GNU Social, Pump.io and Mastodon. The inconvenience is that this is only myself, who knows that several "AndStatus" accounts at different hosts represent the same Actor: for remote observers these Accounts only happen to have the same (or similar) Usernames... In Twitter I have "AndStatus1" username, because "AndStatus" was taken earlier...

[rhiaro]

I think I agree with all of your last message.

You are still confusing a User with an Account. Here should be "there are two Accounts behind that". Both accounts, belonging to a single Actor

I almost wrote accounts, there, except I thought we just agreed that according to AP, an Actor is equivalent to an account.

At the time writing this specification we don't know (didn't decide yet on) how to globally implement multiple Accounts for an Actor in a reliable and secure enough way, but such implementations could be easily created for private/client's solutions

Right... and we don't have time to figure this out. Hence the solution needs to be implementation-specific, or an extension, or otherwise discussed further in the CG.

This is a limitation of AP, we understood that from the start [of this thread] but it's not a show stopper for implementations who want to take this concept further. So I don't see what other changes we need to make in the spec, other than clearing up confusing uses of "user" etc?

[yvolk]

@rhiaro I agree that we shouldn't make now changes to the specification, which would require changes in implementations. But I still think that in order to show all readers / implementers (and to us reading the spec tomorrow) that we understand limitations of current version of the protocol, we need to add to its text (including Overview) words that explain the same for them without reading this long thread.

1. This addition will be a good help for those implementers, who already today feel the need to go beyond these limits in order to create even more advanced federation...
2. Moreover, communicating this extended domain model (including Account notion) today will ease understanding and development of solutions that will break the limits and allow creation of the next version of the ActivityPub specification.
3. And the last but not least. As I think you are aware, I'm not the only one Social networking systems developer, who thinks that current version of ActivityPub spec is not good enough, and that it needs to separate what we now call Actor from Account. Building correct domain model will give such people a unified way forward, and not a disappointment in W3C's ability to create good specification for a "federation of websites"...

[cwebber]

You are still confusing a User with an Account. Here should be "there are two Accounts behind that". Both accounts, belonging to a single Actor, usually will be owned by the same one User (unless maybe the Actor is some Organization ("group Actor") like e.g. "SiteAdmin" actor, where several people, working as admins of the same site, are posting messages as the same Actor but using their own Accounts...)

If I'm understanding right, this is exactly what Profile is for, and why we wrote that it may be used as an Actor in ActivityPub...

[rhiaro]

And the last but not least. As I think you are aware, I'm not the only one Social networking systems developer, who thinks that current version of ActivityPub spec is not good enough, and that it needs to separate what we now call Actor from Account

I'm not sure what you're referring to. Do you have a link to where this was raised elsewhere?

The last discussion we had about this was on AS2 two years ago. You might be interested to read the notes, although the meeting minutes are somewhat hard to follow:

• Paris F2F (this is where we resolved addition of Profile to AS2)
• Issue 17
• Issue 26 (which superseded 17 in the end)

we need to add to its text (including Overview) words that explain the same for them without reading this long thread

Would you mind drafting (either here or in a PR) what would satisfy you for this?

I've re-read all of the comments so far, and if I may summarise where I think we're at:

• Actor as used by AP is equivalent to an account on a server.
• We're not modelling "users" or real world entities like people and organisations; so there's no scope for saying eg. "Chris has two accounts" or "these two Actors (accounts) are controlled by Chris".
• If an implementation wishes to have one Actor (account) controlling multiple profiles, they can extend with Profile from AS2.

I think we all have the same general model in our head, just that the terminology is a little out of sync. We're stuck with the terminology from AS2, so we just need to be clear about what they mean in AP. Eg.

several people, working as admins of the same site, are posting messages as the same Actor but using their own Accounts

translates in AP terms to "several people working as admins of the same site, are posting messages as the same Profile but using their own Actors.

[yvolk]

I'm not sure what you're referring to. Do you have a link to where this was raised elsewhere?

@rhiaro See these recent posts: https://loadaverage.org/conversation/9377312

Posts in this long discussion: https://github.com/swicg/general/issues/1 - also refer to the problem, raised in this issue.

[rhiaro]

I see "Something that separates identity, message distribution, and message content." as the only related comment in that thread that isn't by you.

Keeping identity separate is what we're trying to do by using Actors as accounts as far as the protocol is concerned, and adding no more layers regarding that so that implementations can managed the nuanced identity needs of their users separately.

(Aside: I appreciate that you raised the issue here rather than complaining about it in the fediverse where WG members aren't necessarily even going to see it).

[rhiaro]

Posts in this long discussion: swicg/general#1 - also refer to the problem, raised in this issue.

This thread seems to contain lots of examples of using non-HTTP URIs as identifiers for users, so that their content is not tied to a particular server. There's also a lot of discussion about the threat models, and how non-HTTP URIs can be used to hijack content. It seems pretty clear we can't solve this in time to include in AP to get to REC.

@yvolk Would your preferred outcome be that AP doesn't go to REC without this being solved?

Or do you think the editorial changes we're working on are sufficient for a REC that can be extended as we've discussed, as the community gets closer to solving these more complex user/account/portability problems going forward?

[cwebber]

This thread seems to contain lots of examples of using non-HTTP URIs as identifiers for users, so that their content is not tied to a particular server. There's also a lot of discussion about the threat models, and how non-HTTP URIs can be used to hijack content. It seems pretty clear we can't solve this in time to include in AP to get to REC.

There is also no need to change ActivityPub to get non-http URIs to work with a decentralized / nomadic identity route. My paper for Rebooting Web of Trust demonstrated this. So that is something that can be handled post-REC anyway.

[cwebber]

I'd really like to get this issue wrapped up. It seems to me that we don't have any protocol changes suggested. We're already exploring user/content migration in the SocialCG and if for some reason Profile is not good enough and if we'd like to discuss what such workflows would look like, the SocialCG is a great venue. Can we move conversation there?

We're hoping to put out our last editorial CR on Tuesday. It would be nice if we could have this issue wrapped up by then.

[cwebber]

@yvolk I'd suggest that if there's something to still be added to the AP spec, maybe it's how to use Profile to manage separate "sub-accounts" type things? What do you think?

Or could you suggest other phrasing? If you could do so by tomorrow that would be great. What can we do to get this issue closed in time for CR?

[yvolk]

I see "Something that separates identity, message distribution, and message content." as the only related comment in that thread that isn't by you.

@rhiaro These words by Mike from that thread are about the same: "Unfortunately, ActivityPub frequently confuses data and transport and puts a lot of additional constraints on the data which aren't present in AS2. Keeping the AP data restrictions separated from the lower AS2 data layer so that the transport layer can be cleanly replaced is a bit of a challenge"

[yvolk]

I'd really like to get this issue wrapped up. It seems to me that we don't have any protocol changes suggested. We're already exploring user/content migration in the SocialCG and if for some reason Profile is not good enough and if we'd like to discuss what such workflows would look like, the SocialCG is a great venue. Can we move conversation there?

@cwebber I don't understand, whom are you arguing with here? :-) As I wrote in my answer to you in https://github.com/w3c/activitypub/issues/260#issuecomment-340240795 possibility of Account (not Actor !} implementation using Profile is really another topic.

Suggestions to close this issue instead of understanding the problem and figuring out, how to solve it, is not productive for us here. In my yesterday's comment https://github.com/w3c/activitypub/issuets/260#issuecomment-340267138 I gave my reasons, why I think that the spec needs changes even while these changes wouldn't require changes in implementations. I understand that you didn't read them also :-(

[cwebber]

I read all of your comments @yvolk! A lot of them I think @rhiaro replied to so I didn't further so as to avoid noise on the thread. But I'm confused as to what to do at this point. I think it sounds like you really want us to have a notion of Account with a capital-A in the spec, but there's no such concept in the ActivityStreams vocabulary (we don't have a capital-s-Server anywhere in the spec afaik, and Actor, while not a superclass any more, does have a specific group of AS2 objects that are modeled as Actors). So what can we do?

• Add a capital-A-Account, as a new piece of vocabulary: as said previously, this is off the table due to a prior resolution by the SocialWG.
• Add a capital-A-Account as a not-piece-of-vocabulary, trying to do the vague super-grouping (which is IMO confusing) that AS2 did with Actor: I think in some ways this is still defining new vocabulary, and I'm very hesitant about this. It would also mean confusingly replacing a lot of chunks of the text with a new term that isn't referenced anywhere in the vocabulary, adding a lot of overhead. I'm -1 on that.
• Add a note describing how to do lowercase-a-account using Profile: This is something we can do and I'd be all for it. We've already taken a step towards this with this section of 49b060cd and I'd be happy to expand it further.

So I think that last path is the only one open to us in terms of ActivityPub core itself. I've read all your messages and very carefully but at this point the concept of the Actor (which really to ActivityPub is mostly just something with an inbox and outbox that is slotted for an actor field on activities) is the fundamental notion in ActivityPub. We can help conceptually bridge the divide of how that links to what people use as accounts, and how to do sub-accounts using Profile, but in terms of further domain modeling beyond that I don't think there's something to be done in ActivityPub core.

[rhiaro]

I thought we already agreed that AP describes accounts as "actors", right?

So instead of defining "account" separately, we actually need to make it super clear that they're the same thing. "Actor" may be an awkward word to you for this concept, but from an AS2 perspective it makes sense. But it really does just mean "account" as you've described your "account" concept.

And all AP knows is accounts. It just calls them "actor". But AP doesn't have a more complex concept of system users than that (whether in the real-world direction towards humans or in the online personas/aspects direction towards profiles). Because that's all it needs to ship messages around.

The note in 49b060cd looks good to me, and we could add to it that an actor may equally be a bot or automated process of some kind, to further emphasise the decoupling from 'real world' 'users'. An "actor" to AP is simply something that generates an activity.