Nostr View

PABLOF7z @PABLOF7z - 2y

NIP-95 is a terrible idea

undefined
undefined
undefined

psic4t @psic4t - 2y

Why? Seems pretty neat to me.

undefined
undefined
undefined

99bb5 - 2y

I don't know. Maybe we should have dedicated file storage relays? Would it still be a terrible idea? What's a better idea?

undefined
undefined
undefined

The Fishcake🐶🐾 & 763 others @The Fishcake🐶🐾 - 2y

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! 🐶🐾🫡

undefined
undefined
undefined

The Fishcake🐶🐾 & 763 others @The Fishcake🐶🐾 - 2y

And of course, there are legal implications, etc. 🐶🐾🫡

undefined
undefined
undefined

JeffG @JeffG - 2y

💯 So many better ways to solve that problem than shoehorning binary files into relays.

undefined
undefined
undefined

PABLOF7z @PABLOF7z - 2y

shut up and take my jpeg!

undefined
undefined
undefined

gek @gek - 2y

This! Treat it separately. Heavy duty relays. Need to figure out options for economic models.

undefined
undefined
undefined

8e432 - 2y

Yes 😂

undefined
undefined
undefined

Русский бот @mikedilger - 2y

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)

undefined
undefined
undefined

PABLOF7z @PABLOF7z - 2y

you mean... NosDav? nosdav.com 😉 nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24

undefined
undefined
undefined

Русский бот @mikedilger - 2y

What? It's already done?!

undefined
undefined
undefined

PABLOF7z @PABLOF7z - 2y

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

undefined
undefined
undefined

phil @phil - 2y

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.

undefined
undefined
undefined

Русский бот @mikedilger - 2y

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.

undefined
undefined
undefined

PABLOF7z @PABLOF7z - 2y

nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24 has thought about everything we will think in the next five years

undefined
undefined
undefined

PABLOF7z @PABLOF7z - 2y

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s already has I will tighten my relays rules to prevent this

undefined
undefined
undefined

d3411 - 2y

我在不久前曾经讨论过【存储sRelay】来搭建WEB3存储，其实开启了 #NIP95 能接受文件的Relays就接近了。 想了一下，只要NIP95不是强制各Relay必须实施的，且大多Relay因开启成本较高而未开启，那么就问题不大。可以拓展 #Nostr 的应用场景。整体来说应该算是好事儿 #8Nostr 不必太恐慌。 lightning:[email protected] 🐇ᥬ[🐕]᭄🌿 nostr:nevent1qqsqsam378a8gpph4xk6v6jga973m3u7senely67j04l7gkred4vsggpr9mhxue69uhhyetvv9ujumn0wd68y6trdqhxcctwvspzp56pzqrq0q3n0jyxflmkxgdgy8edh08mpwense93e3y8z24asj5qqvzqqqqqqyt4j253

undefined
undefined
undefined

Русский бот @mikedilger - 2y

I gotta zap that bastard

undefined
undefined
undefined

Русский бот @mikedilger - 2y

If I had paid more attention instead of being head down in my own project, I would have already known.

undefined
undefined
undefined

PABLOF7z @PABLOF7z - 2y

if someone had already started nostr optech it would be easier to keep up 😅

undefined
undefined
undefined

Русский бот @mikedilger - 2y

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.

undefined
undefined
undefined

melvincarvalho @Melvin Carvalho - 2y

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.

undefined
undefined
undefined
Showing page 1 of 1 pages