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

čt 4. 5. 2023 v 21:31 odesílatel Bob Wyman <bob@wyman.us> napsal:

> 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.
>
> 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.)
>
> 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.
>

Um, it's not really a proposal.  More like the boilerplate for a design.
Without code yet.

One thing I really agree with though is that protocols should not be tied
to any *one* transport mechanism.  Whether it be HTTP or websockets or
something that might come along years later.

If I could have one wish for the fediverse, it would be that.


>
> bob wyman
>
>