3 ms·

One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new message

by zaphar 3y ago

One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new messages to every single one of the people following them. This means that if 10 users are following me from the same server I will not have 1 push for that instance, I'll gave 10 pushes for the same single unchanged message. This is built into the protocol. That's a lot of throughput for something that could be much much less chatty. Now on my single instance it's not too bad because 1. I follow maybe 40 people and 2. I have like max 10 followers. For an instance with people with high follower counts across multiple other instances it could get to be a problem fast. Edit: my previous description used fetch when it should have used push.

Spivak 3y ago
Isn't that "more than once instance" rather than "more than one user"? I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.
- zaphar 3y ago
  Yes, I edited my comment too be more clear and. I shouldn't have referred to it as fetch because it's actually push.
  - zaphar 3y ago
    I should note that as a protocol I suspect that ATProto is less chatty which does translate to reduced costs. It adds features on top that some may or may not want which increase costs in other ways but only for the people who want to utilize those features. It's not exactly an Apples to Apples comparison.
lucideer 3y ago
> This is built into the protocol. I haven't implemented AP from scratch so I may be missing technical details precluding this, but it sounds like it may at least partially be covered by https://www.w3.org/TR/activitypub/#shared-inbox-delivery https://www.w3.org/TR/activitypub/#shared-inbox-delivery ... in which case it may be an implementation issue? Mind you, there is liberal use of "MAY" there which I find is always a problem with specs: that would likely lead to mandatory chattiness of outgoing requests if you're federated with a lot of instances without shared inbox support, but should at least solve for incoming.
- zaphar 3y ago
  In theory it would help. In practice since a server can't rely on this it probably devolves to just ignoring that feature.
  - sleepybrett 3y ago
    There can be an interrogation endpoint/message of supported versions/extensions to the base protocol, that's a very normal thing. If it supports bundled delivery, send a single bundle if not send them all individually.
    - zaphar 3y ago
      Yep, And I'm sure there are some instances that do exactly that. But in a distributed protocol you only get the benefit if both sides of a given interaction support the optimization. For something in the spec that is optional you can't rely on it and you aren't forced to implement it so it's not irrational to just ignore it. Which typically means you only get occasional marginal benefit.
      - sleepybrett 3y ago
        i mean it depends. The vast majority of fedi traffic is mastodon. Add it to mastodon it makes an impression and a real difference. At first mastodon to mastodon comms, but others will take notice, it will find it's way into libraries then it's smooth sailing.
sleepybrett 3y ago
I'm not to into the weeds of activitypub yet but in my head it seems like you could add some things to the protocol to optimize this. 1. server with the sender constructs a map by receiving server that contains a list of all users on that server who should receive the message. 2. sending server iterates the map. If the receiving server has multiple recipients do a check to see if the receiving server supports this kind of 'bundled' delivery. 2a. If so send the message once with a list of receivers. 2b. receiving service processes the one message and delivers it to all the users. 3. If not sending server sends it in the traditional way, multiple pushes.

by zaphar 3y ago

Spivak 3y ago

Isn't that "more than once instance" rather than "more than one user"? I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.

zaphar 3y ago
Yes, I edited my comment too be more clear and. I shouldn't have referred to it as fetch because it's actually push.
- zaphar 3y ago
  I should note that as a protocol I suspect that ATProto is less chatty which does translate to reduced costs. It adds features on top that some may or may not want which increase costs in other ways but only for the people who want to utilize those features. It's not exactly an Apples to Apples comparison.

lucideer 3y ago

> This is built into the protocol. I haven't implemented AP from scratch so I may be missing technical details precluding this, but it sounds like it may at least partially be covered by https://www.w3.org/TR/activitypub/#shared-inbox-delivery https://www.w3.org/TR/activitypub/#shared-inbox-delivery ... in which case it may be an implementation issue? Mind you, there is liberal use of "MAY" there which I find is always a problem with specs: that would likely lead to mandatory chattiness of outgoing requests if you're federated with a lot of instances without shared inbox support, but should at least solve for incoming.

zaphar 3y ago
In theory it would help. In practice since a server can't rely on this it probably devolves to just ignoring that feature.
- sleepybrett 3y ago
  There can be an interrogation endpoint/message of supported versions/extensions to the base protocol, that's a very normal thing. If it supports bundled delivery, send a single bundle if not send them all individually.
  - zaphar 3y ago
    Yep, And I'm sure there are some instances that do exactly that. But in a distributed protocol you only get the benefit if both sides of a given interaction support the optimization. For something in the spec that is optional you can't rely on it and you aren't forced to implement it so it's not irrational to just ignore it. Which typically means you only get occasional marginal benefit.
    - sleepybrett 3y ago
      i mean it depends. The vast majority of fedi traffic is mastodon. Add it to mastodon it makes an impression and a real difference. At first mastodon to mastodon comms, but others will take notice, it will find it's way into libraries then it's smooth sailing.

sleepybrett 3y ago

I'm not to into the weeds of activitypub yet but in my head it seems like you could add some things to the protocol to optimize this. 1. server with the sender constructs a map by receiving server that contains a list of all users on that server who should receive the message. 2. sending server iterates the map. If the receiving server has multiple recipients do a check to see if the receiving server supports this kind of 'bundled' delivery. 2a. If so send the message once with a list of receivers. 2b. receiving service processes the one message and delivers it to all the users. 3. If not sending server sends it in the traditional way, multiple pushes.