- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 24 May 2023 23:27:25 +0200
- To: Bob Wyman <bob@wyman.us>
- Cc: public-swicg@w3.org
- Message-ID: <CAKaEYh+poceGVX21K3vHSc6KCZDYqMwmcxbHJeq_=HwXfFaPcQ@mail.gmail.com>
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 >> >>
Received on Wednesday, 24 May 2023 21:27:42 UTC