I added a couple of sentences clarifying FEP-ef61 design goals. In particular:
1. "This document describes web gateways, which use HTTP transport. However, the data model and authentication mechanism are transport-agnostic and other types of gateways could exist."
FEP-ef61 is designed to be compatible with any transport protocol, including the sneakernet. For example, it should be possible to replace web gateways with iroh nodes.
2. Location discovery using DID services. It came to my attention that some developers are trying to implement a variation of FEP-ef61 where gateways are specified in a DID document instead of an actor document. That significantly differs from existing FEP-ef61 implementations (Streams and Mitra), and has a serious practical disadvantage: it doesn't work with generative DID methods such as did:key. Support for pure key-based identities is important for several reasons:
- It is very useful for client-to-client (#p2p) communication without servers. - Interoperability with other protocols that use public keys as identities. #Nostr is probably the most popular, but there are many more. - It lowers the barriers to entry for client developers, who otherwise would need to deploy a did:web or something more complicated like did:webvh.
If media identifier only contains a digest, the gateway can't restrict access to it. This may not be a big problem because digest is very hard to guess, but an access control mechanism still might be useful. One way to implement it is to add an 'ap' identifier of a parent document to a hashlink and make it mandatory.
Why does #nostr feel like a bunch of individual app platforms all vying to keep you on their app and use their Lightening Network thing... oh right. Follow the money, I guess.
It all feels very "See it's all open and free but just sign up here and log into this, and connect this and then you can do all the things!"
Nostr needs someone like @grunfink@comam.es to write an easy to self-host platform/app for it, and a Lightening wallet to suit. But I'd actually rather just see napcop in the wild first I reckon.
Anyway, at least here I can self host something and it just works. Maybe that just shows ActivityPub's age/maturity.
And maybe I'm just looking at it wrong. Nostr seems like it had/has great potential, even if crypto-bros seem to have taken it over.
Post from @rabble on why he's chosen to use #Nostr and not #ActivityPub and the #Fediverse. He makes some compelling points. Personally I am not too worried about the server admin parts of his argument (I have enough control, even if I don't control the server), but I agree that this isn't ideal:
Hay una propuesta de extension para #ActivityPub que descentraliza aun mas el #Fediverso con un funcionamiento similar a #Nostr dando mas "poder" a los clientes. Esto es bastante interesante, ya que el usuario tendria mas control sobre su cuenta y no la "perdería" si un nodo cierra.
Folks: #Twitter is now owned by a horrible new billionaire… Foget the fediverse, let’s use #Bluesky & #Nostr by the billionaire who created Twitter instead.
Meanwhile…
‘When a Twitter user commented there was “not a chance the DNC allows him to be nominated,” Dorsey replied, "Even more reason.” He later added that the DNC “seems more irrelevant by the day” and wrote “end of an empire,” to which Tesla CEO and current Twitter owner Elon Musk replied with two fire emoji.’
Just pushed an extensive update to FEP-fffd (Proxy Objects), which explains the process of merging posts with their proxies and removes the need for extra context entries. This should hopefully be the final syntax for this feature.