Re: Melvin's microfed.org proposal. Is there a better way forward?

pá 5. 5. 2023 v 1:06 odesílatel Erin Shepherd <erin.shepherd@e43.eu> napsal:

>
> On Thu, 4 May 2023, at 21:30, Bob Wyman wrote:
>
> Melvin Cavalho proposes
> <https://lists.w3.org/Archives/Public/public-swicg/2023May/0013.html>:
>
> But we should also consider the whole open social web and one space.
> Working to create bridges will benefit everyone.  Today I started on a
> design of a micro framework for tedi that can implement AP and also other
> protocols, including Solid.
> https://microfed.org/
>
>
> I am concerned that the proposal for yet-another protocol may, in fact,
> take us farther from where we want to go, rather than closer. I can't help
> wondering if there is some way to move forward by taking the best of the
> alternative, existing protocols and defining them as extensions to existing
> SocialWeb protocols or as inter-protocol bridges. For instance, there is
> already "Mostr," a Nostr <-> ActivityPub bridge
> <https://soapbox.pub/blog/mostr-fediverse-nostr-bridge/> that was
> developed to win a bounty posted by fiatjaf
> <https://gist.github.com/fiatjaf/ea7d21e81359e1eb8abcb8805306adaa>.
>
> Mostr acts as an ActivityPub server and as a Nostr client. It has an
> ActivityPub inbox which converts data into Nostr events which it pushes to
> a Nostr relay. It also listens on the relay and federates ActivityPub data
> for relevant Nostr events. The general pattern there seems to be very much
> what one would get from integrating WebSub into the ActivityPub network.
> The conceptual similarities between a WebSub server and a Nostr relay are
> significant. (Except that a Nostr relay sometimes does more than simply
> providing PubSub, store-and-forward, service for messages.)
>
> One of the issues I have with ActivityPub today is that it requires use of
> a specific transport protocol for messages. It does more than simply define
> message content and syntax. Thus, you can't have an ActivityPub-compliant
> interface that uses anything other than HTTP GET and POST. It seems to me
> that this restriction is unnecessary even if most implementers will be
> happy to support only HTTP and aren't concerned about the inherent
> inefficiency or latency that is required by HTTP polling. A more generally
> useful and future-proof ActitvityPub specification would allow
> the implementation of at least client-server APIs over WebSockets. Of
> course, if we were to do that, then clients that spoke "ActivityPub over
> WebSockets" would be well on their way to also speaking Nostr --
> particularly if something like Mostr was available to bridge between the
> application protocols.
>
>
> It's not clear to me what polling you're talking about here. In the C2S
> protocol? Sure, though that's not really in wide use. It's unfortunate
> nothing better is defined there, true, but it wouldn't be hard to extend.
> You're always going to end up with the polling fallback anyway (if nothing
> else but as one way to handle backlog fetches during periods when a client
> is offline)
>
> FWIW you don't *need* to go all the way to WebSockets here; given
> relative proportions of download to upload, Server Sent Events
> <https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events>
> or something similar would be absolutely fine.
>
> But the actual widely deployed bit of ActivityPub is S2S, which is not
> polled.
>
> An ActivityPub server that supported WebSockets wouldn't have to deprecate
> its default HTTP implementation and a server that only supported HTTP
> wouldn't be inherently "deficient." Both interfaces could be easily
> supported, side-by-side. Which interface was used would depend on how a
> client connects to the server. If you connect via WebSockets, you'd be
> subscribed to have updates pushed to you as they are being inserted into
> your InBox. But, if you connected via HTTP, you'd have to poll for updates,
> as you do today. Message formats, sequences, etc. would not have to change.
>
> One of the good things about Nostr relays is that their use solves one of
> the commonly observed problems with ActivityPub as defined. ActivityPub
> messages sent to "Public" are only exchanged between servers that know each
> other. Thus, one's view of message traffic depends heavily on which server
> you use as your primary. However, if we were to define an ActivityPub
> variant of WebSub, which would act much as a Nostr relay does, we'd be able
> to allow servers to send "Public" messages to a WebSub server and for all
> other servers to subscribe to messages from that server. This would reduce
> the cost and complexity of public message distribution as well as the cost
> and complexity of receiving or finding them. Given such intermediary WebSub
> redistributing relays, it would be much easier to maintain a consistent
> view of the global discourse than appears common with ActivityPub today. It
> is also likely that such a system would reduce the current advantage that
> large instances have over small instances. (i.e. The larger your home
> instance, the more complete will be your view of the overall message
> traffic. This large-server advantage is unnecessary.)
>
>
> ActivityPub relays are *a thing that already exists* and are supported by
> *all* of the major fediverse implementations today. If this is a problem
> you (as an instance admin) have, you can subscribe to a relay. There are
> probably hundreds of them, with thousands of instances subscribed! I know
> of ~4 different implementations of AP relay servers as well.
>
> *In practice* many admins of smaller servers, including myself, much
> prefer to not receive the firehose of the entire fediverse; it keeps our
> federated timeline relatively useful, allows us to have longer remote user
> message retention, etc. The fact that we exist in our own bubble is to us a
> feature, not a curse.
>

Hi Erin

These are great insights.

Im curious about how your server would fare if fediverse were to grow 10x

Is the firehose the thing that is limiting?

Would larger instances develop longer queues or resource issues?


>
> Now, yes, AP relays don't replace the direct public message distribution
> process, but that's also sort of the point: on nostr you can't talk to a
> friend who is on a different relay (unless both of your relays are
> connected with each other). You're always going to need direct distribution
> unless both servers can somehow know that they're connected to the same
> relay and trust it's reliability.
>
> One of the nice side-effects of WebSocket use is that it allows us to
> think about protocol extensions that would be odd given ActivityPub's
> reliance on high-latency HTTP polling. For instance, one can imagine
> implementing games like chess over WebSockets, but less so over ActivityPub
> or any other polling protocol. (e.g. Imagine timed moves in a chess game.
> It is really hard to properly time moves if there is polling latency in
> their propagation...) Not surprisingly, there are those who have been
> working on game protocols using Nostr... Given that games are inherently
> "social," I'd like to see similar innovation in the ActivityPub world. Why
> not?
>
> Would anyone else be interested in working on a spec for "*ActivityPub
> over WebSockets*" and also potentially a "*WebSub for
> ActivityPub/ActivityStreams*?" I believe these are things that could be
> developed as optional extensions within the SWICG and without requiring
> modifications to the base protocols.
>
> bob wyman
>
>
> ActivityPub is not a polled protocol; I don't know where you get this
> idea. This is especially the case for AP *in practice*, i.e. where the
> Mastodon API (or similar) is typically used for client-to-server
> interactions, which has Server Sent Event and Websocket streaming
> endpoints! The idea that there is a latency problem in practice is also
> strange to me; the latency between me posting a reply to someone (on a
> different server) and hearing their laptop make a notification bloop is
> not, in my experience, noticably different from the same experience with an
> instant messaging protocol.
>
> It's really not clear to me that WebSockets would actually result in a
> practical or noticable reduction in federation overhead or latency compared
> to just HTTP/2.0 between servers; which is something easy to deploy without
> any protocol changes in AP (and which is probably already deployed; I just
> haven't bothered digging into the HTTP libraries used by the various
> projects).
>
> AP over WebSockets feels to me like a pet project of yours that you've
> talked about a lot based upon an assumption of a need that doesn't seem to
> have a basis in fact. The scaling challenges you - and many people here -
> talk about are not the ones I hear from *the* *actual implementers*.
>
> - Erin
>