Re: "Evolving ActivityPub to reduce infrastructure costs"

There are many ways of reducing operating costs that don't involve changing
the protocol.
At work, if the web app hosting bills get high, I don't change the http
protocol or html spec. I change the way I'm implementing the protocol, e.g.
by routing traffic first through a reverse proxy cache like varnish
<https://varnish-cache.org>.
There are a lot of people operating implementations of this protocol that
have never operated a high traffic web service before.

I believe the specific bit of duplication you're showing will not increase
operating costs in the wild, because in the wild most people serving HTTP
support at least gzip compression. Mastodon supports gzip and more. This is
one of the nice things about building on HTTP is message size reduction
over the wire can be solved by transfer-encoding negotiation using http
norms.
Thus I think the only cost of the example you provide might be the cost of
computing those JSON strings. (which you can avoid doing unnecessarily with
help of a cache).

> I suspect it would be easily possible to reduce message length by 50%,
even without compression, just by avoiding redundancies.
How much does the person you cited as caring about this think that 50%
message length reduction (on only messages of this form) will lower their
overall operating bill?
How much compared to adding a reverse proxy cache in front of the existing
protocol?

I think the latter is going to help them accomplish their goals better, and
doesn't involve a protocol change.

Last thing worth noting on server costs is if this person is basing their
cost estimate on running mastodon, they should also compare operating costs
of implementations of the protocol that aren't in Ruby.





On Tue, Mar 14, 2023 at 4:28 PM Johannes Ernst <johannes.ernst@gmail.com>
wrote:

> This was brought up by somebody as a subject to talk about in the
> questionnaire we ask for FediForum [1] attendees when they sign up.
>
> Looking at real-world messages as they are being sent around today, I
> sympathize with this comment. I suspect it would be easily possible to
> reduce message length by 50%, even without compression, just by avoiding
> redundancies.
>
> Random example from my Mastodon outbox:
>
>       *"published"**: *"2023-03-14T17:44:24Z"*,*
>
>       *"to"**: [*
>
>         "https://www.w3.org/ns/activitystreams#Public"
>
> *      ],*
>
> *...*
>
>       *"object"**: {*
>
>         *"id"**: *"
> https://social.coop/users/J12t/statuses/110022876518950247"*,*
>
>         *"type"**: *"Note"*,*
>
> *...*
>
>         *"published"**: *"2023-03-14T17:44:24Z"*,*
>
>         *"to"**: [*
>
>           "https://www.w3.org/ns/activitystreams#Public"
>
> *        ],*
>
> Without changing anything, really, just documenting the right defaults
> would reduce the two “to” entries and the two “published” entries to one
> each.
>
> I don’t know whether the particular individual had other things in mind
> beyond message size reduction.
>
> But IMHO it would be worthwhile to look at ActivityPub from the
> perspective of efficiency as well in future work. Maybe make a list of
> potential candidates in the meantime?
>
> Best,
>
>
>
> Johannes Ernst
> Blog: https://reb00ted.org/
> FediForum: https://fediforum.org/
> Dazzle: https://dazzle.town/
>
>
>
> [1] https://fediforum.org/ — online, 2 half days, end of the month, you
> are all invited :-) Disclaimer: I am a co-organizer.
>