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

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.

bob wyman