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

I'm almost ready to do a bit more work on microfed.org .  But I realize
that while I have design documentation, I dont have a high level
documentation explaining what microservices in fediverse could look like.

So I will aim to write something about that over the summer.

My wish list:
- backwards compatible with existing systems
- small modular components that can run alone or together
(profile,inbox,outbox,auth)
- 100% standards compliant
- uses best practices in Linked Data
- bridges or adaptors to existing systems (Solid, Nostr, Mostr, more...)
- ability for users to own their private keys
- nomadic identity where users can move from one service to another

I think that is an outline of the thing that I will document next

Bill's idea of "*ActivityPub over WebSockets*" is very interesting

It's potentially something I'd like to work on, because it may be simple
and useful.  Mostr may be doing some of this already.  It seems to me you
would just open an endpoint then send activity messages to it.  Could be a
2 page spec saying how to do that.

But I'll try and do the first high level micro services document first,
then maybe some implementation work around micro profiles.


>
> bob wyman
>
>