NIP-95 is a terrible idea
Discussion
Why? Seems pretty neat to me.
I don't know. Maybe we should have dedicated file storage relays? Would it still be a terrible idea? What's a better idea?
Yes, still a bad idea. Unless you run and dedicated relay for documents in a limited corporate environment, this has major scaling drawbacks that are not even worth dancing around! 🐶🐾🫡
And of course, there are legal implications, etc. 🐶🐾🫡
This! Treat it separately. Heavy duty relays. Need to figure out options for economic models.
Yes 😂
IMHO WebDAV with a few extensions handled in the HTTP headers is what we need.
We don't need an online held-open protocol, a stateless request-response is sufficient.
The WebDAV PROPFIND/PROPATCH being in XML is dumb but usable for applying tags, and HTTP headers for certain things like 'content-type', 'range', etc, all well specified already.
We would want to be able to authenticate and to set/specify permissions (on get, put, patch, delete, but also rename, setperms, lock, delete a prop)
you mean... NosDav?
nosdav.com 😉
nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24
What? It's already done?!
of course it is, this is nostr!
😂
zapstr.live uses this for paid tracks
I have a modified nosdav server listening for zaps on paid tracks; when the right zapper zaps the track, the pubkey is whitelisted for downloads of that event's media
Holy fuck, and it has a spec, NAVs, and it actually looks like what I was thinking except it's been actually thought out.
I should have known I wouldn't be the first person to think of that.
nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 has thought about everything we will think in the next five years
- JSON instead of XML - done
- stateless request - done
- http headers - done
- range requests - todo
- GET - yes
- PUT - yes
- DELETE - todo
- auth - done
- patch - interesting one, which to use, I think maybe json patch or linked objects, or n3 patch
- lock - todo
- setperms - partially done, more todo
- access control - todo
Basically cherry picked the best things from : https://solid.mit.edu/
Nice. Glad it's JSON not XML. I meant PATCH as in the HTTP verb.
Tried to zap you but Wallet of Satoshi told me there was some problem with the LNURL
Solid is Tim Berners-Lee right? Haven't heard that for a while.
Now I see you on the solid.mit.edu page. 👍
Yes, I worked with TimBL on it, for quite a while and it's becoming a w3c REC hopefully in the next 1-2 years, but it's not yet stable. Nostr is stable, working today, so I can port the best parts over to nostr.
Somehow I thought HTTP PATCH was well defined, like byte offsets into a binary blob or something.[1] I don't know why we would need PATCH.
nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24
[1] This is the first time I said something stupid on nostr.[2]
[2] Please don't double check.
Patch is useful to send less over the wire and for rapidly changing documents, also for large documents
Solid went for n3 patches which are adding or deleting items associated with a URI, which is the linked data way
JSON Patch is based on Json paths and trees
Linked Objects is a simpler version that ties values to uris
An important aspect of patch is that the data in a file is not the same as a filename, and can contain many things or concepts. So patching a file is closely coupled to the transport, patching the data is transport agnostic, and therefore, more decentralized.
I do believe we need a better solution for decentralised file hosting. While the current media hosts are probably suitable for most general use, we lose a lot content if one is shut down. I don’t think encoding binary content on the relays is the best solution though. I think some relay operators may look to block this either due to bandwidth/storage or legal concerns.
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s already has
I will tighten my relays rules to prevent this
What? Hosting in urls is not a "decentralized solution"... 🙄
And would IPFS be better? That would just open up a can of worms?
no, more worms
Are you against:
A) Clients trying to shoehorn binary blobs into notes, and relays needing to explicitly block that
or
B) The entire concept of relays hosting files, even if it's explicitly opt-in for relays that choose to do that?
It is. There isn’t enough financial incentive to make literally all media on nostr censorship resistant. It’s already expensive enough to host and serve media as it is. If you need your media to be censorship resistant you can already do so by self hosting.