New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relation between Actors and Users of servers is undefined #260

Closed
yvolk opened this Issue Sep 29, 2017 · 67 comments

Comments

Projects
None yet
6 participants
@yvolk

yvolk commented Sep 29, 2017

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 yvolk changed the title from Relation between Actors and Users of servers is not defined to Relation between Actors and Users of servers is undefined Sep 29, 2017

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 1, 2017

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.

yvolk commented Oct 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Oct 1, 2017

nightpool commented Oct 1, 2017

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 1, 2017

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

yvolk commented Oct 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 2, 2017

Collaborator

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

Collaborator

cwebber commented Oct 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 3, 2017

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

yvolk commented Oct 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 10, 2017

Collaborator

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.

Collaborator

cwebber commented Oct 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 10, 2017

Collaborator
<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
Collaborator

cwebber commented Oct 10, 2017

<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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 12, 2017

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

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

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

yvolk commented Oct 12, 2017

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

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

  1. Attributes of a User are presented as attributes of an Actor in examples...
@strugee

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Oct 13, 2017

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 :)

strugee commented Oct 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 13, 2017

@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 commented Oct 13, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 20, 2017

@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 :-)
?!

yvolk commented Oct 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Oct 20, 2017

@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 commented Oct 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Oct 20, 2017

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

strugee commented Oct 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Oct 21, 2017

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.

sandhawke commented Oct 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 21, 2017

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

yvolk commented Oct 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Oct 21, 2017

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.

sandhawke commented Oct 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Oct 21, 2017

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

strugee commented Oct 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@sandhawke

sandhawke Oct 24, 2017

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

sandhawke commented Oct 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 24, 2017

@sandhawke Good, thank you for the clarification. In my notes on what's mixed/confused and needs to be changed (see #260 (comment) ) 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 commented Oct 24, 2017

@sandhawke Good, thank you for the clarification. In my notes on what's mixed/confused and needs to be changed (see #260 (comment) ) 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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 24, 2017

@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 #260 (comment) ), 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 #263

yvolk commented Oct 24, 2017

@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 #260 (comment) ), 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 #263

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 24, 2017

Member

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.

Member

rhiaro commented Oct 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 24, 2017

Member

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

Member

rhiaro commented Oct 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 24, 2017

@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"...
?!

yvolk commented Oct 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 24, 2017

Member

@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.
Member

rhiaro commented Oct 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 24, 2017

Member

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

Member

rhiaro commented Oct 24, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 24, 2017

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.

yvolk commented Oct 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 29, 2017

Member

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

Member

rhiaro commented Oct 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 29, 2017

Member

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?

Member

rhiaro commented Oct 29, 2017

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 comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 29, 2017

Collaborator

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.

Collaborator

cwebber commented Oct 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 29, 2017

Collaborator

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.

Collaborator

cwebber commented Oct 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 30, 2017

Collaborator

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

Collaborator

cwebber commented Oct 30, 2017

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

cwebber added a commit that referenced this issue Oct 30, 2017

Incorporate adjusted description of relationship between users and ac…
…tors

Related to #260.

Thanks to Yuri Volkov for the phrasing!
@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 30, 2017

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 commented Oct 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Oct 30, 2017

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 #260 (comment) 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 :-(

yvolk commented Oct 30, 2017

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 #260 (comment) 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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 30, 2017

Collaborator

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.

Collaborator

cwebber commented Oct 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 30, 2017

Member

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.

Member

rhiaro commented Oct 30, 2017

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.

cwebber added a commit that referenced this issue Oct 30, 2017

Clarify that actor-accounts can be of real-world users, bots, automat…
…ed processes

Based by suggestion by @rhiaro in #260

Also hey look, "accounts"!
@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 30, 2017

Collaborator

Great suggestion @rhiaro! Here's the change I made:

modified   index.html
@@ -144,8 +144,8 @@
       </p>
 
       <p>
-        In ActivityPub, users from the real world are represented by
-        "<a href="#actors">actors</a>". 
+        In ActivityPub, accounts (including those of real-world users, bots,
+        and other automated processes) are represented by "<a href="#actors">actors</a>". 
         Every Actor has:
       </p>

And hey look! I clarified there that actors are accounts :)

Collaborator

cwebber commented Oct 30, 2017

Great suggestion @rhiaro! Here's the change I made:

modified   index.html
@@ -144,8 +144,8 @@
       </p>
 
       <p>
-        In ActivityPub, users from the real world are represented by
-        "<a href="#actors">actors</a>". 
+        In ActivityPub, accounts (including those of real-world users, bots,
+        and other automated processes) are represented by "<a href="#actors">actors</a>". 
         Every Actor has:
       </p>

And hey look! I clarified there that actors are accounts :)

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Oct 30, 2017

Member

I expanded on this further: c038f72

Member

rhiaro commented Oct 30, 2017

I expanded on this further: c038f72

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 30, 2017

Collaborator

That looks really good to me!

Collaborator

cwebber commented Oct 30, 2017

That looks really good to me!

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 30, 2017

Collaborator

@yvolk I think between the last two commits mentioned in this issue we've addressly discussed the relationship between actors and accounts. Does this help enough for you in AP core? (We always have the SocialCG to take on further modeling work outside of the core document.)

Collaborator

cwebber commented Oct 30, 2017

@yvolk I think between the last two commits mentioned in this issue we've addressly discussed the relationship between actors and accounts. Does this help enough for you in AP core? (We always have the SocialCG to take on further modeling work outside of the core document.)

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 31, 2017

Collaborator
<eprodrom>  RESOLVED: Resolve issue #260 as having completed relevant changes
           to ActivityPub itself, and move additional modeling decisions to  
           SocialCG
Collaborator

cwebber commented Oct 31, 2017

<eprodrom>  RESOLVED: Resolve issue #260 as having completed relevant changes
           to ActivityPub itself, and move additional modeling decisions to  
           SocialCG
@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Oct 31, 2017

Collaborator

Hey @yvolk! So we talked about it on the WG call and we think we've done as much as we can do directly in ActivityPub, but agree there is more accounts modeling to be done still (especially in areas like the standard accounts settings and managements work). We'd like to move the remainder of that modeling to the SocialCG... would you like to help guide some of that there?

In the meanwhile I hope the recent changes @rhiaro and I made to the spec helped resolve some of the concerns you had about the relationship between users and accounts being defined? Do you feel that brought some of the clarity you were hoping for?

Collaborator

cwebber commented Oct 31, 2017

Hey @yvolk! So we talked about it on the WG call and we think we've done as much as we can do directly in ActivityPub, but agree there is more accounts modeling to be done still (especially in areas like the standard accounts settings and managements work). We'd like to move the remainder of that modeling to the SocialCG... would you like to help guide some of that there?

In the meanwhile I hope the recent changes @rhiaro and I made to the spec helped resolve some of the concerns you had about the relationship between users and accounts being defined? Do you feel that brought some of the clarity you were hoping for?

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Nov 1, 2017

@rhiaro @cwebber Please give me time to review recent changes and propose additional, if needed.
I plan to work on this tomorrow.

yvolk commented Nov 1, 2017

@rhiaro @cwebber Please give me time to review recent changes and propose additional, if needed.
I plan to work on this tomorrow.

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Nov 2, 2017

  1. Minimal changes to the Overview section, which I made in PR #268, should allow us and other readers/implementers to have common vocabulary in their future discussions.

  2. Additional changes needed (I didn't include them in this PR in order to focus on the main thing): Several replacements of users to Actors / accounts (depending on a context), where the term "user" doesn't mean "real-world users, bots, and other automated processes".

yvolk commented Nov 2, 2017

  1. Minimal changes to the Overview section, which I made in PR #268, should allow us and other readers/implementers to have common vocabulary in their future discussions.

  2. Additional changes needed (I didn't include them in this PR in order to focus on the main thing): Several replacements of users to Actors / accounts (depending on a context), where the term "user" doesn't mean "real-world users, bots, and other automated processes".

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Nov 2, 2017

Collaborator

Hey @yvolk, I'm happy with the changes except I wonder if we can tweak a few words... see https://github.com/w3c/activitypub/pull/268/files#r148635139

What do you think?

Collaborator

cwebber commented Nov 2, 2017

Hey @yvolk, I'm happy with the changes except I wonder if we can tweak a few words... see https://github.com/w3c/activitypub/pull/268/files#r148635139

What do you think?

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Nov 3, 2017

@cwebber @nightpool The words "In this version of ActivityPub each account corresponds to exactly one actor" explain, why in the following document there is no separate account entity with its attributes (URLs etc.), specific to the particular server (on which the account is created), but those attributes appear inside the Actor. This means one-to-one relation between them.
I agree that words "In this version of ActivityPub" may be too promising a concrete way of the specification development :-), so let's drop them: I did this in my update to the PR #268

Why include the line, "an account corresponds to exactly one actor"? That's needlessly and incredibly restrictive, preventing any kind of Tumblr-like "side blog" setup or any kind of company group actor, like tweetdecks "authorized account" feature.
Accounts are completely out of scope for activitypub anyway. I'm fine including more examples of actors but any language beyond that should not be introduced.

@nightpool Thank you for your comment. Please read this thread: it's all about answers to these questions! It took us a month to come to understanding of the terminology to use in our discussion.

The "Overview" section sets a "stage" for a reader, telling him/her a story in the words that the reader presumably knows. The term "account" does have place in that story, because this is exactly how users actually call / know it: we all create account on a server before we are authorized to post anything via the server... So "account" is existing notion in the domain. It may be out of scope of "a formal protocol definition..." (as we see "in this version of ActivityPub" :-) ) but it cannot be out of scope of the document, which connects real-life cases with the formal specification.

yvolk commented Nov 3, 2017

@cwebber @nightpool The words "In this version of ActivityPub each account corresponds to exactly one actor" explain, why in the following document there is no separate account entity with its attributes (URLs etc.), specific to the particular server (on which the account is created), but those attributes appear inside the Actor. This means one-to-one relation between them.
I agree that words "In this version of ActivityPub" may be too promising a concrete way of the specification development :-), so let's drop them: I did this in my update to the PR #268

Why include the line, "an account corresponds to exactly one actor"? That's needlessly and incredibly restrictive, preventing any kind of Tumblr-like "side blog" setup or any kind of company group actor, like tweetdecks "authorized account" feature.
Accounts are completely out of scope for activitypub anyway. I'm fine including more examples of actors but any language beyond that should not be introduced.

@nightpool Thank you for your comment. Please read this thread: it's all about answers to these questions! It took us a month to come to understanding of the terminology to use in our discussion.

The "Overview" section sets a "stage" for a reader, telling him/her a story in the words that the reader presumably knows. The term "account" does have place in that story, because this is exactly how users actually call / know it: we all create account on a server before we are authorized to post anything via the server... So "account" is existing notion in the domain. It may be out of scope of "a formal protocol definition..." (as we see "in this version of ActivityPub" :-) ) but it cannot be out of scope of the document, which connects real-life cases with the formal specification.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Nov 3, 2017

I read that whole thread both as it was happening and again before responding to this issue. I disagree with this changes for reasons stated over and over again in that thread—"accounts", like authentication or UI, is not something activitypub can or should model in any way shape or form.

nightpool commented Nov 3, 2017

I read that whole thread both as it was happening and again before responding to this issue. I disagree with this changes for reasons stated over and over again in that thread—"accounts", like authentication or UI, is not something activitypub can or should model in any way shape or form.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Nov 3, 2017

because this is exactly how users actually call / know it: we all create account on a server before we are authorized to post anything via the server

on your server maybe. What if I want all users to be able to post to any actor, like a decentralized version of 4chan?

nightpool commented Nov 3, 2017

because this is exactly how users actually call / know it: we all create account on a server before we are authorized to post anything via the server

on your server maybe. What if I want all users to be able to post to any actor, like a decentralized version of 4chan?

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Nov 3, 2017

because this is exactly how users actually call / know it: we all create account on a server before we are authorized to post anything via the server

on your server maybe. What if I want all users to be able to post to any actor, like a decentralized version of 4chan?

Account is needed at the point, where the message is introduced to the the "Social network" by some external client. The message may be addressed to any actor, no matter on which server that actor's account resides. At least the word "account" doesn't restrict us in addressing a message to actors. On the contrary, it helps us to express actual actions: tell user stories.

yvolk commented Nov 3, 2017

because this is exactly how users actually call / know it: we all create account on a server before we are authorized to post anything via the server

on your server maybe. What if I want all users to be able to post to any actor, like a decentralized version of 4chan?

Account is needed at the point, where the message is introduced to the the "Social network" by some external client. The message may be addressed to any actor, no matter on which server that actor's account resides. At least the word "account" doesn't restrict us in addressing a message to actors. On the contrary, it helps us to express actual actions: tell user stories.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Nov 3, 2017

nightpool commented Nov 3, 2017

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Nov 3, 2017

User stories having to do with accounts are explicitly outside of the scope of activitypub though

The overview section already has a user story, which includes "account". And "outside of the scope" is not a dogma :-)
In the new revision the story is: "A client to server protocol (so users, including real-world users, bots, and other automated processes, can communicate with ActivityPub using their accounts on servers, from a phone or desktop or web application or whatever)"

And none of this even begins to addresses the problematic implications of "exactly one account per actor"

In the current text of ActivityPub, account-to-actor relation is "close" to the point that it may seem that account is actor, so the phrase "an account corresponds to exactly one actor" doesn't change specification, but changes a view / conceptual understanding of current specification and provides common ground for future discussions.

yvolk commented Nov 3, 2017

User stories having to do with accounts are explicitly outside of the scope of activitypub though

The overview section already has a user story, which includes "account". And "outside of the scope" is not a dogma :-)
In the new revision the story is: "A client to server protocol (so users, including real-world users, bots, and other automated processes, can communicate with ActivityPub using their accounts on servers, from a phone or desktop or web application or whatever)"

And none of this even begins to addresses the problematic implications of "exactly one account per actor"

In the current text of ActivityPub, account-to-actor relation is "close" to the point that it may seem that account is actor, so the phrase "an account corresponds to exactly one actor" doesn't change specification, but changes a view / conceptual understanding of current specification and provides common ground for future discussions.

@yvolk

This comment has been minimized.

Show comment
Hide comment
@yvolk

yvolk Nov 5, 2017

Hi @cwebber @rhiaro @nightpool @jaywink,
I updated the #268 PR another time:

  1. Refined statement on account to actor relation (in the Overview). So now the whole phrase in the Overview is:

In ActivityPub, a user is represented by "actors" via the user's accounts on servers. User's accounts on different servers correspond to different actors. Every Actor has:

  1. Several replacements of "users" to "actors" (and visa versa), where the term "user" doesn't mean "real-world users, bots, and other automated processes".

yvolk commented Nov 5, 2017

Hi @cwebber @rhiaro @nightpool @jaywink,
I updated the #268 PR another time:

  1. Refined statement on account to actor relation (in the Overview). So now the whole phrase in the Overview is:

In ActivityPub, a user is represented by "actors" via the user's accounts on servers. User's accounts on different servers correspond to different actors. Every Actor has:

  1. Several replacements of "users" to "actors" (and visa versa), where the term "user" doesn't mean "real-world users, bots, and other automated processes".
@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Nov 5, 2017

Collaborator

Okay! That last PR looks really good! I also think it takes care of @nightpool's concern about confusing users about whether they can have side-accounts or not. I'm merging it!

Thanks for your work on this @yvolk (and thanks for your input @rhiaro and @nightpool !)

Collaborator

cwebber commented Nov 5, 2017

Okay! That last PR looks really good! I also think it takes care of @nightpool's concern about confusing users about whether they can have side-accounts or not. I'm merging it!

Thanks for your work on this @yvolk (and thanks for your input @rhiaro and @nightpool !)

@cwebber cwebber closed this Nov 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment