People are Starter Packs
Technical Discussion
2
Posts
2
Posters
0
Views
-
I think that my comment on GitHub that Group Actors acting as Starter Packs really comes from how I approach my social network.
I rely on my friends and peers to discover new topics and meet new people.
Friends and peers as Starter Packs work great on a small microblog instance like Mastodon, Misskey, or Sharkey because the federated feed/bubble lists topics written by the amazing people that they are following. This approach is ideal for small instances, but flagship, large and relayed instances make it much harder as the topics are much too diverse.
When a small instance I was part of shutdown, I was really at a loss because I relied heavily on that feature without following people myself i.e. I'm lazy. And so to figure out who to follow, I went back to my peers’ and friends’ following Collection. Note to self, I need to remember to continually discover more people from people I follow now that I am on my own single-actor instance.
This is why I come to the conclusion that people are Starter Packs. Or in other words, Actors are Starter Packs. And more specifically, anyone or thing with a publicly-available following Collection is a Starter Pack.
But making a public directory of everyone is not a good idea and discoverability is hard.
Starter Packs should be (Group) Actors because
- Consent is built-in with the Follow Accept/Reject.
- People that want to explicitly allow followers already have this option.
- Implementations should use Mastodon’s
discoverabilityproperty to also limit who a Starter Pack may follow.
- Revoking consent is mostly built-in with either Remove Follow, Block Undo, or Reject Follow.
- Discoverability is built-in:
- The following Collection is available.
- Group Actors can make posts when their following Collection is updated.
- Amazing UX designers can make the following Collection more usable in their software.
- Starter Packs that are used in bad faith can be defederated like any other bad faith Actor or instance.
- The barrier to implementation is much lower than tacking on anything new to the specification.
- Consent is built-in with the Follow Accept/Reject.
-
mradcliffe@nokoto.org apart from the technical details, this approach also is extremely easy to explain to laypeople.
"Follow who this person follows" :heavy_check_mark:
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian I forgot, why do you want to delete a context? If it's your thread, isn't it enough to just Delete the top-level post?
-
mradcliffe@nokoto.org apart from the technical details, this approach also is extremely easy to explain to laypeople.
"Follow who this person follows" :heavy_check_mark:
-
I think that my comment on GitHub that Group Actors acting as Starter Packs really comes from how I approach my social network.
I rely on my friends and peers to discover new topics and meet new people.
Friends and peers as Starter Packs work great on a small microblog instance like Mastodon, Misskey, or Sharkey because the federated feed/bubble lists topics written by the amazing people that they are following. This approach is ideal for small instances, but flagship, large and relayed instances make it much harder as the topics are much too diverse.
When a small instance I was part of shutdown, I was really at a loss because I relied heavily on that feature without following people myself i.e. I'm lazy. And so to figure out who to follow, I went back to my peers’ and friends’ following Collection. Note to self, I need to remember to continually discover more people from people I follow now that I am on my own single-actor instance.
This is why I come to the conclusion that people are Starter Packs. Or in other words, Actors are Starter Packs. And more specifically, anyone or thing with a publicly-available following Collection is a Starter Pack.
But making a public directory of everyone is not a good idea and discoverability is hard.
Starter Packs should be (Group) Actors because
Consent is built-in with the Follow Accept/Reject.People that want to explicitly allow followers already have this option.Implementations should use Mastodon’s discoverability property to also limit who a Starter Pack may follow.Revoking consent is mostly built-in with either Remove Follow, Block Undo, or Reject Follow.Discoverability is built-in:The following Collection is available.Group Actors can make posts when their following Collection is updated.Amazing UX designers can make the following Collection more usable in their software.Starter Packs that are used in bad faith can be defederated like any other bad faith Actor or instance.The barrier to implementation is much lower than tacking on anything new to the specification.
-
Currently I am grappling with the specifics behind how to federate out the deletion of a topic in a category (or in ForumWG terms, the deletion of a context from an audience.)
For those unaware, a context is essentially an OrderedCollection containing all objects within its purview.
Deleting a note or other object is easy. If you are same-origin as the object, you Delete(Object), done.
Deleting a context is more difficult... you can't rely on other implementors to store references to your contexts, since it is essentially meaningless to them. Furthermore, if a context is deleted, then when a Delete(Context) is federated out, receivers will have no idea what they're seeing, will try to retrieve the object, and find a 404. So it doesn't even work at all.
Even worse, you can't really delete other peoples' contexts (or for that matter, their content) since you're not same-origin.
Finally, I realized I'm looking at this the wrong way — I'm not deleting contexts, I'm simply removing them from an audience. Remove works perfectly fine when the context continues to exist (as it can be referenced and duck typed). Remove also works for remote content; the same-origin check applies to the audience you're removing from.
If you're deleting a context, you have to be the same-origin, and you really should just federate out deletion of the local members in that collection, via regular Delete(Object).
I suppose federating out self-destruction of a context would be the most complete but it is quite difficult to do when it is no longer resolvable...
-
Yes I'm fine with that. It doesn't make much difference in the end.
-
Thanks Rimu. Will give this a shot.
Upon reflection, since Deletes aren't wrapped in an Announce, then I would recommend that any Move activity we use not be wrapped in Announce either.
-
@julian if you give me any specific examples of when you would want to use null, i can recommend better alternatives. generally, it's always possible that there is missing information.
