Something missing from 'followers' and 'following' collections.
-
Something missing from 'followers' and 'following' collections.
1/
ActivityPub 'followers' and 'following' collections tend to be missing an important piece of information —
The date-time when person A followed person B.
There are certain use-cases where this matters.
You can see an example of this information missing in what Mastodon includes in the attached screen-shot.
-
Something missing from 'followers' and 'following' collections.
1/
ActivityPub 'followers' and 'following' collections tend to be missing an important piece of information —
The date-time when person A followed person B.
There are certain use-cases where this matters.
You can see an example of this information missing in what Mastodon includes in the attached screen-shot.
Something missing from 'followers' and 'following' collections.
2/
I think this could be addressed by using the ActivityPub 'published' field:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-published
Such as what is shown in the (new) attached screen-shot.
So that the date-time when person A followed person B is included.
-
? Guest crossposted this topic to General Discussion
-
Something missing from 'followers' and 'following' collections.
1/
ActivityPub 'followers' and 'following' collections tend to be missing an important piece of information —
The date-time when person A followed person B.
There are certain use-cases where this matters.
You can see an example of this information missing in what Mastodon includes in the attached screen-shot.
@reiver that information should exist in the form of the Follow/Accept activities that are in the participating actors' inbox/outboxes.
-
Something missing from 'followers' and 'following' collections.
2/
I think this could be addressed by using the ActivityPub 'published' field:
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-published
Such as what is shown in the (new) attached screen-shot.
So that the date-time when person A followed person B is included.
@reiver This is claiming the actors themselves were published at the given datetime, which is probably not what you want.
I think what you want is a collection of actual follower/following relationships, or possibly a collection of Follow activities, or possibly a collection of subscription records. Those can have a "published" datetime and be understood correctly as when the relation was created (instead of when the actor was created).
-
@reiver This is claiming the actors themselves were published at the given datetime, which is probably not what you want.
I think what you want is a collection of actual follower/following relationships, or possibly a collection of Follow activities, or possibly a collection of subscription records. Those can have a "published" datetime and be understood correctly as when the relation was created (instead of when the actor was created).
@reiver FWIW, I actually think that a collection of subscriptions / "follower relationships" is needed for other reasons! Mainly, to help with desync issues in follower state that plague the fediverse today in practice. (I know in a lot of cases people are interested in knowing directly "who is a follower" and not indirectly via "which follower relationships exist", but the former is currently broken and the latter would fix those issues.)
-
@reiver FWIW, I actually think that a collection of subscriptions / "follower relationships" is needed for other reasons! Mainly, to help with desync issues in follower state that plague the fediverse today in practice. (I know in a lot of cases people are interested in knowing directly "who is a follower" and not indirectly via "which follower relationships exist", but the former is currently broken and the latter would fix those issues.)
@reiver Having an explicit notion of a "follower relationship" or a "subscription" is useful for other reasons, too -- like, say, being able to specify which activities one is interested in receiving. Or the datetime of last successful delivery, so that inactive followers can be marked inactive instead of destroying the follow relationship entirely.
-
@reiver Having an explicit notion of a "follower relationship" or a "subscription" is useful for other reasons, too -- like, say, being able to specify which activities one is interested in receiving. Or the datetime of last successful delivery, so that inactive followers can be marked inactive instead of destroying the follow relationship entirely.
In the past I've been advocating a lot for what I called at the time "community has no boundary", basically relating to the formation of richer social graphs.
Follow is basically "I subscribe to your feed", while the social graph might express much richer relationships than that. The current way we do it makes everything a microblog, subscribing to a single feed spout.
We have the Relationship object.
"I follow you as a sponsor for your work"
"I am co-worker in this team"
"I am a subsidiary of this organization"Etcetera.
-
In the past I've been advocating a lot for what I called at the time "community has no boundary", basically relating to the formation of richer social graphs.
Follow is basically "I subscribe to your feed", while the social graph might express much richer relationships than that. The current way we do it makes everything a microblog, subscribing to a single feed spout.
We have the Relationship object.
"I follow you as a sponsor for your work"
"I am co-worker in this team"
"I am a subsidiary of this organization"Etcetera.
@smallcircles @reiver Sadly the as:Relationship concept is underdefined and underutilized (and arguably duplicative of as:Link).
I don't think Follow makes *everything* into a microblog, though. By default, the Follow does nothing, actually. Even when you Accept Follow, it just adds them to the followers collection. You have to address and deliver to the followers collection for it to mean anything. You are free to address or deliver to arbitrary audiences that *don't* include your followers.
-
@smallcircles @reiver Sadly the as:Relationship concept is underdefined and underutilized (and arguably duplicative of as:Link).
I don't think Follow makes *everything* into a microblog, though. By default, the Follow does nothing, actually. Even when you Accept Follow, it just adds them to the followers collection. You have to address and deliver to the followers collection for it to mean anything. You are free to address or deliver to arbitrary audiences that *don't* include your followers.
True about Follow. There are some motivating use cases in ActivityStreams that might be hardened in their design to become like standardized protocol capabilities one can rely on, some business/application domain specific. And then follow/unfollow might be formalized as a robust mechanism for publish/subscribe to another actor in your social graph.
https://www.w3.org/TR/activitystreams-vocabulary/#motivations
-
@reiver that information should exist in the form of the Follow/Accept activities that are in the participating actors' inbox/outboxes.
Agreed.
But, it would also be nice to have it in the 'followers' and 'following' collection pages.
-
@reiver This is claiming the actors themselves were published at the given datetime, which is probably not what you want.
I think what you want is a collection of actual follower/following relationships, or possibly a collection of Follow activities, or possibly a collection of subscription records. Those can have a "published" datetime and be understood correctly as when the relation was created (instead of when the actor was created).
I meant to use "url" rather than "id" in that sample code I wrote.
But, your broader point is still correct. I do more or less want a collection of Follow and Accept[Follow] activities.
-
Agreed.
But, it would also be nice to have it in the 'followers' and 'following' collection pages.
@reiver but the proposal you're suggesting is so incompatible with anything ActivityPub related or Activity vocabulary in general, that it's not really tenable.
I think we all need to start thinking of the social API of ActivityPub, not as a graphql correspondent, where API callers get all their information in one request, but as one (of many) source of truth, on top of which we layer some other abstraction that offers the elements that we want to show.
So it's less about presenting users the followers collections directly, but more about extracting meaningful information from that collection and collate it with other elements form their inbox/outbox.
-
@reiver but the proposal you're suggesting is so incompatible with anything ActivityPub related or Activity vocabulary in general, that it's not really tenable.
I think we all need to start thinking of the social API of ActivityPub, not as a graphql correspondent, where API callers get all their information in one request, but as one (of many) source of truth, on top of which we layer some other abstraction that offers the elements that we want to show.
So it's less about presenting users the followers collections directly, but more about extracting meaningful information from that collection and collate it with other elements form their inbox/outbox.
The information in the followers and followings collections is already in the outbox.
Why bother with the followers and followings collection if they are not the source-of-truth, and we could just iterate through the outbox instead?
To me they (the followers and followings collections) seem like a "projection" of (some of) the data in the outbox — to make things more tractable and developer-friendly.
-
The information in the followers and followings collections is already in the outbox.
Why bother with the followers and followings collection if they are not the source-of-truth, and we could just iterate through the outbox instead?
To me they (the followers and followings collections) seem like a "projection" of (some of) the data in the outbox — to make things more tractable and developer-friendly.
@reiver well, I disagree about iterating through outbox to infer the followers collection. ActivityPub describes an exact behaviour that results in an actor being added to it.
Having that logic implemented in every client feels absurd.
But having logic to compute the time for "follower since" from an outbox/inbox in every client that wants to display it seems less absurd (to me). I can understand if you don't.
BTW, I'm not saying that having that information in the followers/following collection is not worth it, but that the change required to have that happen, moves you away from ActivityPub into maybe ActivityPub v2, or something else all together.
-
Something missing from 'followers' and 'following' collections.
1/
ActivityPub 'followers' and 'following' collections tend to be missing an important piece of information —
The date-time when person A followed person B.
There are certain use-cases where this matters.
You can see an example of this information missing in what Mastodon includes in the attached screen-shot.
Tangential to the main discussion, I'd like to point out that folks here get *very* nervous when this kind of data gets collected and you need to show that you've very carefully thought through how to keep from enabling harassment.
-
I meant to use "url" rather than "id" in that sample code I wrote.
But, your broader point is still correct. I do more or less want a collection of Follow and Accept[Follow] activities.
@reiver I guess thinking about it a bit more, the reason it can't really be Follow or Accept Follow activities on its own is that any future Reject Follow may or may not exist without your knowledge. So there needs to be an entity separate from the activities to act as a sort of "record" of the current state inherent to a resource rather than a "record" of the state change inherent to some action.
-
I meant to use "url" rather than "id" in that sample code I wrote.
But, your broader point is still correct. I do more or less want a collection of Follow and Accept[Follow] activities.
@reiver @trwnh Do you want to record when A offered to Follow B or when the relationship was actually established (after an Accept/Follow)? If it's the latter, if you change "url" to "href" in your second example, it would imply AS2 Links and the `published` property would be for the Link itself (when the relationship was created) rather than the original Follow activity.
-
@reiver @trwnh Do you want to record when A offered to Follow B or when the relationship was actually established (after an Accept/Follow)? If it's the latter, if you change "url" to "href" in your second example, it would imply AS2 Links and the `published` property would be for the Link itself (when the relationship was created) rather than the original Follow activity.
-
@reiver @trwnh Do you want to record when A offered to Follow B or when the relationship was actually established (after an Accept/Follow)? If it's the latter, if you change "url" to "href" in your second example, it would imply AS2 Links and the `published` property would be for the Link itself (when the relationship was created) rather than the original Follow activity.
-
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login