Notices tagged with activitypub, page 4
-
@silverwizard wrote: "AndStatus is an Android app for OStatus clients"
This is wrong. #OStatus is a server-to-server protocol, #AndStatus connects to servers using server-to-client protocols. This is why AndStatus doesn't know and doesn't depend on OStatus protocol.
Moreover, #Mastodon 's client-to-server protocol is still based on outdated Twitter like API, not on #ActivityPub, unfortunately.
@jackyalcine -
@zatnosk @banjofox have you looked into #ActivityPub or #Zot @fla ?
-
@randomascii you don't need an account on an instance to follow someone on it, as long as it federates using #OStatus or #ActivityPub
-
@6gain I know about this problem. Will fix as soon as I complete current large changes, which I'm doing (moving to #ActivityPub data model)
-
@jark Reviewing and improving #ActivityPub specification is not about coding/programming. It's about analysis and modeling. But my experience shows that it's hard to notice problems and mistakes in such documents, until you don't try to start actually using it in practise, in this case - starting to implement some application using this specification OR starting to adapt this specification, as an Analyst, for some concrete application. This way you will read every phrase, some of them - many times...
@mike @verius @clacke @cwebber -
@jark Reviewing and improving #ActivityPub specification is not about coding/programming. It's about analysis and modeling. But my experience shows that it's hard to notice problems and mistakes in such documents, until you don't try to start actually using it in practise, in this case - starting to implement some application using this specification OR starting to adapt this specification, as an Analyst, for some concrete application. This way you will read every phrase, some of them - many times...
@mike @verius @clacke @cwebber -
@cwebber@octodon.social The same for me: Only implementing now domain model of #ActivityPub /#ActivityStreams in my #AndStatus application I became deep enough aware of the specs' advantages and shortcomings... so I initiated another round of the spec fixes. Sorry that not months ago...
@bea @teascade @neon -
@cwebber@octodon.social The same for me: Only implementing now domain model of #ActivityPub /#ActivityStreams in my #AndStatus application I became deep enough aware of the specs' advantages and shortcomings... so I initiated another round of the spec fixes. Sorry that not months ago...
@bea @teascade @neon -
@cwebber@octodon.social Thank you for reply to the #ActivityPub issue at https://github.com/w3c/activitypub/issues/260
I followed the discussion there plus copying my follow-up below:
1. Let's go step by step. Explicitly stating that Actors and Users are different entities is a good way forward.
BTW the confusing phrase "users are represented as "actors" here" should also be changed to "users are mapped to actors" with addition, how (you suggested wording...)
Where can we see current draft for review how it looks now? You are too quick to state that the issue is resolved :-)
2. Let's check if the statement is valid:
* ""user" is technically an entity outside the protocol"
2.1 First of all the term is used tens times in the document, which describes the protocol: https://www.w3.org/TR/activitypub/
2.2. The term "user" is used for two different things, actually:
* for "natural person from a real world"
* and for "user's account at a Servetr" (my interpretation).
The second meaning is definitely "inside protocol". Just look at these phrases, from many available, for example:
* "This protocol permits a client to act on behalf of a user."
* "Client to server interaction takes place through clients posting Activities to a user's outbox"
My conclusion is that a User in the second meaning "user's account at a Server" is definitely a part of the protocol description.
3. As now we agreed on separation of an Actor from a User, let's look again, what we read in the document.
3.1 You know: there are many places, where the word user(s) should be replaced with a word Actor(s), e.g. here {again, one of many examples):
* "The Follow activity is used to subscribe to the activities of another user."
Attributes of a User are presented as attributes of an Actor in examples... -
@cwebber@octodon.social Thank you for reply to the #ActivityPub issue at https://github.com/w3c/activitypub/issues/260
I followed the discussion there plus copying my follow-up below:
1. Let's go step by step. Explicitly stating that Actors and Users are different entities is a good way forward.
BTW the confusing phrase "users are represented as "actors" here" should also be changed to "users are mapped to actors" with addition, how (you suggested wording...)
Where can we see current draft for review how it looks now? You are too quick to state that the issue is resolved :-)
2. Let's check if the statement is valid:
* ""user" is technically an entity outside the protocol"
2.1 First of all the term is used tens times in the document, which describes the protocol: https://www.w3.org/TR/activitypub/
2.2. The term "user" is used for two different things, actually:
* for "natural person from a real world"
* and for "user's account at a Servetr" (my interpretation).
The second meaning is definitely "inside protocol". Just look at these phrases, from many available, for example:
* "This protocol permits a client to act on behalf of a user."
* "Client to server interaction takes place through clients posting Activities to a user's outbox"
My conclusion is that a User in the second meaning "user's account at a Server" is definitely a part of the protocol description.
3. As now we agreed on separation of an Actor from a User, let's look again, what we read in the document.
3.1 You know: there are many places, where the word user(s) should be replaced with a word Actor(s), e.g. here {again, one of many examples):
* "The Follow activity is used to subscribe to the activities of another user."
Attributes of a User are presented as attributes of an Actor in examples... -
@mike@macgirvin.com I agree that #ActivityStreams2 is well designed. Maybe this is exactly because its ideas are actively tested in practice for several years in pump.io. Confusion of Actors and Users of servers in the #ActivityPub I regard as a conceptual mistake that should be fixed _now_. So I proposed concrete additions to the spec in this issue: https://github.com/w3c/activitypub/issues/260
Not many responses so far :-( -
@mike@macgirvin.com I agree that #ActivityStreams2 is well designed. Maybe this is exactly because its ideas are actively tested in practice for several years in pump.io. Confusion of Actors and Users of servers in the #ActivityPub I regard as a conceptual mistake that should be fixed _now_. So I proposed concrete additions to the spec in this issue: https://github.com/w3c/activitypub/issues/260
Not many responses so far :-( -
@zoowar This is exactly what I propose in this #ActivityPub specification bug report: https://github.com/w3c/activitypub/issues/260
Separation of Actors (e.g. a Person) from Users of servers (user accounts) even on a conceptual (domain model level). Please support this fix!
@mike @cwebber -
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
@mike@macgirvin.com What do you this is a better alternative to #ActivityPub? Or maybe something concrete could be changed in its current version to make it better?
-
yvolk
mmn
, Gargron
, lnxw48a1
, deadsuperhero
, cwebber
, citizenphnix
, FuzboleroXV
I filed a bug for #ActivityPub, which 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.
See https://github.com/w3c/activitypub/issues/260
@fuzboleroxv @citizenphnix
@cwebber @gargron @deadsuperhero @mmn @lnxw48a1 -
yvolk
mmn
, Gargron
, lnxw48a1
, deadsuperhero
, cwebber
, citizenphnix
, FuzboleroXV
I filed a bug for #ActivityPub, which 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.
See https://github.com/w3c/activitypub/issues/260
@fuzboleroxv @citizenphnix
@cwebber @gargron @deadsuperhero @mmn @lnxw48a1 -
@cwebber Reposting to make sure you received my reply. Where should I file this #ActivityPub issue?
The #ActivityPub spec's problem is not in that simplistic phrase "users are represented as actors here".
The problem is that there is NO technical description of the whole domain model layer: relation between Actors (e.g. Person) and Users of servers. Current version will be interpreted as having one-to-one relation between the two _different_ kinds of entities, and that _is_ incorrect
?!
My first post on this subject was:
Contemplating on correct implementation of a data model, corresponding to the #ActivityPub specification, I started to realize that current version of the document https://www.w3.org/TR/activitypub has a gap/confusion of two different notions: Person (one of Actor types, see https://www.w3.org/TR/activitystreams-vocabulary/#dfn-person ) and a User of a server (quote from ActivityPub spec: "users are represented as "actors" here")
Actually these are very different notions: a Person may be represented as more than one User, on different servers. And a User may represent not a Person, but e.g. an Organization.
?!
@clacke -
@cwebber Reposting to make sure you received my reply. Where should I file this #ActivityPub issue?
The #ActivityPub spec's problem is not in that simplistic phrase "users are represented as actors here".
The problem is that there is NO technical description of the whole domain model layer: relation between Actors (e.g. Person) and Users of servers. Current version will be interpreted as having one-to-one relation between the two _different_ kinds of entities, and that _is_ incorrect
?!
My first post on this subject was:
Contemplating on correct implementation of a data model, corresponding to the #ActivityPub specification, I started to realize that current version of the document https://www.w3.org/TR/activitypub has a gap/confusion of two different notions: Person (one of Actor types, see https://www.w3.org/TR/activitystreams-vocabulary/#dfn-person ) and a User of a server (quote from ActivityPub spec: "users are represented as "actors" here")
Actually these are very different notions: a Person may be represented as more than one User, on different servers. And a User may represent not a Person, but e.g. an Organization.
?!
@clacke -
@cwebber The #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
?! -
@cwebber 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
?! -
@elizafox @chriswere sounds like #ActivityPub allows a much larger range of federated functions than #OStatus
http://qttr.at/1y2h
