bblfish on Nostr: #Solid should learn from both #Mastodon #ActivityPub and #nostr. Here are initial ...
#Solid should learn from both #Mastodon #ActivityPub and #nostr.
Here are initial thoughts:
1. Linking WebIDs to nostr keys could easily be done with an owl:sameAs statement
<https://bblfish.net/people/henry/card#me>; owl:sameAs <did:key:…>
btw. What do #nostr folks recommend: did:key or did:jwk: or something else ???
2. The same could be done with redirecting if one loses one’s personal domain
old:WebID owl:sameAs new:WebID .
And a statement such as
new:WebId webid:deprecates “https://bblfish.net/people/henry/card#me”^^xsd:anyUri .
3. The major innovation of #nostr is the use of keys and the signing of all content. That should be integrated into #solidproject.
(Should headers be added for each signed content? for example? A header like
Author: did:key: …
Signature: …. <- using just released Signing HTTP Messages RFC? https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0124.html
Interestingly that gives a reason for having server signatures that don’t sign the URL!
4. Another innovation is using the lightning network: Solid should integrate that.
Nostr makes a very good case that it works and is fun as one zaps people’s posts (note Apple asked apps to remove that feature!)
A Quick look at the protocol, and I wonder:
1. does one need sockets for posting content? Could that not just be a POST to a solid container?
2. Nip 01 comes with a simple query mechanism. My main problem is that these are not restful. If it returned just URLs for new content, that could be sent quickly down the wire. Even better with SPDY (still looking for a #scala implementation)
But an even lower cost search could be #LDES (Linked Data Event Streams https://joinup.ec.europa.eu/collection/semic-support-centre/linked-data-event-streams-ldes ), which is just like RSS but with a tree structure and non changing
3. Also, the format is unnecessarily not extensible.
Still #nostr is a very good demonstration of what solid hyper apps are meant to be.
Here are initial thoughts:
1. Linking WebIDs to nostr keys could easily be done with an owl:sameAs statement
<https://bblfish.net/people/henry/card#me>; owl:sameAs <did:key:…>
btw. What do #nostr folks recommend: did:key or did:jwk: or something else ???
2. The same could be done with redirecting if one loses one’s personal domain
old:WebID owl:sameAs new:WebID .
And a statement such as
new:WebId webid:deprecates “https://bblfish.net/people/henry/card#me”^^xsd:anyUri .
3. The major innovation of #nostr is the use of keys and the signing of all content. That should be integrated into #solidproject.
(Should headers be added for each signed content? for example? A header like
Author: did:key: …
Signature: …. <- using just released Signing HTTP Messages RFC? https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0124.html
Interestingly that gives a reason for having server signatures that don’t sign the URL!
4. Another innovation is using the lightning network: Solid should integrate that.
Nostr makes a very good case that it works and is fun as one zaps people’s posts (note Apple asked apps to remove that feature!)
A Quick look at the protocol, and I wonder:
1. does one need sockets for posting content? Could that not just be a POST to a solid container?
2. Nip 01 comes with a simple query mechanism. My main problem is that these are not restful. If it returned just URLs for new content, that could be sent quickly down the wire. Even better with SPDY (still looking for a #scala implementation)
But an even lower cost search could be #LDES (Linked Data Event Streams https://joinup.ec.europa.eu/collection/semic-support-centre/linked-data-event-streams-ldes ), which is just like RSS but with a tree structure and non changing
3. Also, the format is unnecessarily not extensible.
Still #nostr is a very good demonstration of what solid hyper apps are meant to be.