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

st 24. 5. 2023 v 21:25 odesílatel Melvin Carvalho <melvincarvalho@gmail.com>
napsal:

>
>
> č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've captured the goals in this wish list in a starter document with
codename "Activity-LD" (LD = Linked Data)

https://github.com/micro-fed/activity-ld/

Just notes at the moment, but I can hopefully flesh it out this summer,
then implement and test


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