I didn't mean for it to be the first post in the Starter Pack discussion space, but I've posted my idea for an alternative approach, if that's something that interests you: https://github.com/mastodon/featured_collections/discussions/3
Technical Discussion
12
Posts
3
Posters
0
Views
-
One question that's worth considering is: In what context would Bluesky-style Starter Packs work best?
They work in Bluesky in part because that network is structured to give every new account global reach by default.
But imagine that you join a Mastodon server and subscribe to a Starter Pack, only to find that 95% of the accounts it collects are hosted on a defederated server. Is that helpful?
My suspicion is that the single context where fediverse Starter Packs would work best is the orbit around mastodon.social.
@lrhodes I live in a small country with some really small Mastodon instances - some of them are personal or just a few friends. In this context, having a starter pack with «many active posters in your country» would be really useful for newbies, IMHO.
-
@lrhodes I live in a small country with some really small Mastodon instances - some of them are personal or just a few friends. In this context, having a starter pack with «many active posters in your country» would be really useful for newbies, IMHO.
@hallvors But only if those active posters are accessible from the server you're on. And in the context you're describing, federation becomes an even bigger wedge for determining who is and is not accessible.
That's one of my big cautions about Bluesky-style starter packs: They don't really account for federation. I'm not sure there's any way they could be made to do so.
-
@hallvors But only if those active posters are accessible from the server you're on. And in the context you're describing, federation becomes an even bigger wedge for determining who is and is not accessible.
That's one of my big cautions about Bluesky-style starter packs: They don't really account for federation. I'm not sure there's any way they could be made to do so.
Not following the argument. Can you explain more about why they don't account for federation? Perhaps with an example of the problem as you see it.
Edit: Looking at your Venn diagram, it seems like the concern is that smaller instances will be underrepresented. But, just playing Devil's advocate, couldn't the opposite also be true? That is, people on smaller instances that would not otherwise be visible to each other, could be joined through the pack.
-
Not following the argument. Can you explain more about why they don't account for federation? Perhaps with an example of the problem as you see it.
Edit: Looking at your Venn diagram, it seems like the concern is that smaller instances will be underrepresented. But, just playing Devil's advocate, couldn't the opposite also be true? That is, people on smaller instances that would not otherwise be visible to each other, could be joined through the pack.
Really not trying to be a 'reply guy' here, and hoping for a real discussion as you seem to have thought this through. Here is the scenario referenced above. User A, a long time user with many contacts throughout the Fediverse whom they interact with about subject Z, so they create a subject Z pack. Anyone who loads the Z pack, people on big and small instances, now follows all the people, even those on small instances that they would never have found otherwise.
-
Really not trying to be a 'reply guy' here, and hoping for a real discussion as you seem to have thought this through. Here is the scenario referenced above. User A, a long time user with many contacts throughout the Fediverse whom they interact with about subject Z, so they create a subject Z pack. Anyone who loads the Z pack, people on big and small instances, now follows all the people, even those on small instances that they would never have found otherwise.
@mastodonmigration Anyone who loads the Z pack now follows all of the people… on servers that are federated with theirs.
And on some packs, that will be fine. If you're on the same server as user A, that Venn diagram might well be a circle. If I follow a pack from a Merveilles user, then I shouldn't see any broken connections. But the devs are insisting that Starter Packs must be federated so that people on different servers can share lists. And I just don't see anyway that can work as smoothly here as it does on a mediated network like Bluesky.
Which is part of why I say that the context Starter Packs serve best is mastodon.social — a hundred-thousand or so people who barely see the effects of federation because they're federated to all the same servers as most of the people that they already follow… because they're all on the same server.
-
undefined julian shared this topic on
System shared this topic on -
@hallvors But only if those active posters are accessible from the server you're on. And in the context you're describing, federation becomes an even bigger wedge for determining who is and is not accessible.
That's one of my big cautions about Bluesky-style starter packs: They don't really account for federation. I'm not sure there's any way they could be made to do so.
@lrhodes the «networked instances» model offers fewer guarantees in general - not only defederation, but instances that might have simply disappeared. So I think starter packs here inherently are a sort of best-effort thing.
-
@mastodonmigration Anyone who loads the Z pack now follows all of the people… on servers that are federated with theirs.
And on some packs, that will be fine. If you're on the same server as user A, that Venn diagram might well be a circle. If I follow a pack from a Merveilles user, then I shouldn't see any broken connections. But the devs are insisting that Starter Packs must be federated so that people on different servers can share lists. And I just don't see anyway that can work as smoothly here as it does on a mediated network like Bluesky.
Which is part of why I say that the context Starter Packs serve best is mastodon.social — a hundred-thousand or so people who barely see the effects of federation because they're federated to all the same servers as most of the people that they already follow… because they're all on the same server.
Had a thought about this starter pack issue within the context of the Federated vs. Mediated frame, discussed in the other thread. At a high level, because packs span federations, they in essence need to be a mediated construct, and users can not rely of the mechanisms of federation to keep them safe.
-
Had a thought about this starter pack issue within the context of the Federated vs. Mediated frame, discussed in the other thread. At a high level, because packs span federations, they in essence need to be a mediated construct, and users can not rely of the mechanisms of federation to keep them safe.
@mastodonmigration I think that could be true, depending on how they're implemented. (And assuming I understand your meaning.) Right now, it looks like the Mastodin devs are planning to have packs federate the same way that messages do, and I expect that the only way to keep that from being an exercise in frustration will be to only display accounts that are visible to both the pack creator and the user installing the pack. Presumably, that would also curb some potential safety issues, but I suppose it could open others. I'm still wrapping my head around how this could work in a genuinely federated context.
-
@mastodonmigration I think that could be true, depending on how they're implemented. (And assuming I understand your meaning.) Right now, it looks like the Mastodin devs are planning to have packs federate the same way that messages do, and I expect that the only way to keep that from being an exercise in frustration will be to only display accounts that are visible to both the pack creator and the user installing the pack. Presumably, that would also curb some potential safety issues, but I suppose it could open others. I'm still wrapping my head around how this could work in a genuinely federated context.
It's only a half-baked thought. Also still trying to sort it all out. Like the idea of only showing users visible to both. Had not heard that before.
-
It's only a half-baked thought. Also still trying to sort it all out. Like the idea of only showing users visible to both. Had not heard that before.
@mastodonmigration That's mostly me speculating, based on what would be least frustrating. Though I suppose there could be a safety angle, too.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
fentiger@mastodon.social yes I was also thinking of the venerable 429.
evan the thing is, both approaches rely on the receiving end to support it. I would make the argument that a 429 would have nominal support from some implementations, but then again I wouldn't actually bet money on it.
Either way you're looking at an FEP to establish flow control signalling or 429 handling. I'd then make the argument that putting together guidance for 429 (+ exponential back off) is easier than specifying flow control logic.
-
@evan No, you haven't. You just need to back off and retry, just as you do for an ACK timeout in TCP.
-
fentiger@mastodon.social yes, but by that point you've failed. What I want is to have more adaptive sending, so you don't get to the 429 code.
-
-
Obviously the other option is to keep sending until the receiving server fails, and then do exponential backoff until the remote server can process your activity again.
But I'm looking for something more adaptive that adjusts the sending rate before the receiver fails.
-
I've been thinking lately about flow control. That's a feature of some networks where a receiver can tell a sender to slow down its sending rate to match the receiver's processing rate.
In TCP flow control, the receiving host returns a receiving buffer size in its acknowledgement segment, so the sending host know how much data it can send without overflowing the buffer.
I wonder if there are ways that a receiving ActivityPub protocol server could tell the sending server to slow down? Maybe we could reuse some of the RateLimit headers.
Another option would be a special header that says how big your incoming activity queue is. "I have a very long processing queue right now, please keep stuff in your outgoing queue for a while."
-
@flancian It's an egregiously backwards-incompatible change, so probably no.
-
@julian Pages should be real containers, not slices of the collection like "last 25 items".
