#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.
bblfish /
npub1m0…nn0rv
2023-08-18 12:34:31
in reply to nevent1q…hdtx
Author Public Key
npub1m0wym3srryqtkt9uuev43arglv4083p9redzep85ayurv53xsmas9nn0rvPublished at
2023-08-18 12:34:31Event JSON
{
"id": "8a4e53f8a1d22a52968eab7a980d347162881b73a6d439ed5d1fd9f96f4ffdd9",
"pubkey": "dbdc4dc6031900bb2cbce65958f468fb2af3c4251e5a2c84f4e93836522686fb",
"created_at": 1692354871,
"kind": 1,
"tags": [
[
"e",
"c960b3ec233aade3229b41a179ff092d8fd51ef59e9172a79bec3f7030326db3",
"wss://relay.mostr.pub"
],
[
"e",
"d6710fd28ada59d42be246f04026db9446d2e7e284cbf4108c1e8a9d3312eb14"
],
[
"p",
"b7471ee072dd4baed58f0ae76edb7f1f85ae8662e143887b50f8648e8d9e0825"
],
[
"t",
"solid"
],
[
"t",
"mastodon"
],
[
"t",
"activitypub"
],
[
"t",
"nostr"
],
[
"t",
"nostr"
],
[
"t",
"nostr"
],
[
"t",
"solidproject"
],
[
"t",
"scala"
],
[
"t",
"ldes"
],
[
"t",
"nostr"
]
],
"content": "#Solid should learn from both #Mastodon #ActivityPub and #nostr. \nHere are initial thoughts:\n1. Linking WebIDs to nostr keys could easily be done with an owl:sameAs statement\n \u003chttps://bblfish.net/people/henry/card#me\u003e owl:sameAs \u003cdid:key:…\u003e \n btw. What do #nostr folks recommend: did:key or did:jwk: or something else ???\n2. The same could be done with redirecting if one loses one’s personal domain\n old:WebID owl:sameAs new:WebID .\n And a statement such as \n new:WebId webid:deprecates “https://bblfish.net/people/henry/card#me”^^xsd:anyUri .\n3. The major innovation of #nostr is the use of keys and the signing of all content. That should be integrated into #solidproject. \n (Should headers be added for each signed content? for example? A header like \n Author: did:key: …\n Signature: …. \u003c- using just released Signing HTTP Messages RFC? https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0124.html\n Interestingly that gives a reason for having server signatures that don’t sign the URL! \n \n4. Another innovation is using the lightning network: Solid should integrate that. \n 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!)\n\nA Quick look at the protocol, and I wonder: \n1. does one need sockets for posting content? Could that not just be a POST to a solid container? \n2. 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)\nBut 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 \n3. Also, the format is unnecessarily not extensible.\n\nStill #nostr is a very good demonstration of what solid hyper apps are meant to be.",
"sig": "e60950a03b396716c969a5b31b99045ece84709c18e77204e608a0aa218879466c10d5588640ab214f423029f823147deb66558318b304f3ef0c361e03a85021"
}