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 ***@***.***> 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 <#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?)