bud09: rehosting and blob adoption #39
Conversation
|
The goal makes sense. I don't have any other particular feedback just yet. |
|
There is probably a way to incorporate cross server agreement to mirror files between them if the user chooses to do so. Let's say Bob has his own server hosted privately, and also pays for some other publicly hosted service that he wants to use for general access. If Bob uploads a file to his own server, the server pushes the event or request to the other public service to fetch/mirror the file for the purposes of sharing as a primary source. |
There was a problem hiding this comment.
I like the idea although I feel like it would make sense to focus more on the blob hashes instead of the event ids
also maybe the adoption and rehosting events could be the same kind and structure but the temp rehosting event would have a NIP-40 expiration tag on it?
|
|
||
| 1. `bob` publishes a note with id `<x>` containing a URL to `https://bob.blossom/<hash>`; | ||
| 2. Later `alice` sees that post and decides to keep that file alive by uploading it to her server: `https://alice.blossom/<hash>`; | ||
| 3. After uploading it, `alice` publishes an event `{"kind": 1063,"tags":[["e","<x>"]]}`, which means she has adopted all the media files contained in event `<x>`; |
There was a problem hiding this comment.
Referencing the event id here seems like an unnecessary step. if Alice likes the content and wants to adopt it why not just directly reference the hashes using an x tag? (although having multiple would mean you couldn't reuse the 1063 kind)
There was a problem hiding this comment.
on which relay would you look for x references? from whom? I just feel that having the rehost event reference another event gives it a sense of locality. it would be probably found on the relay of the original poster, for example.
could be ok if we just defined those relay preferences in the BUD.
There was a problem hiding this comment.
Good point, although there isn't any harm with including the x tags? I'm looking at it from the other way and I think there might be a use for clients or users looking up specific hashes and discovering who is currently hosting them and maybe what note they where tied to
There was a problem hiding this comment.
If they have no idea of in what relay to look for it is useless, we will be pushing people to use a few central "global state" relays, i.e. just use the Damus relay and whatnot.
I think the genius of Blossom is that it ties hashes to the context of who posted that. This BUD is an attempt to enhance that context.
I was unsure about adding direct hashes in adoption events, but I guess it is fine as one can choose to not rehost all the contents that may be referred by an event but only a part.
So yes, I think we should have the x tag there instead of the e tag. But the BUD must be explicit about the relays to which these events should be submitted and where they should be looked for.
| 1. `bob` publishes a note with id `<x>` containing a URL to `https://bob.blossom/<hash>`; | ||
| 2. Later `alice` sees that post and decides to keep that file alive by uploading it to her server: `https://alice.blossom/<hash>`; | ||
| 3. After uploading it, `alice` publishes an event `{"kind": 1063,"tags":[["e","<x>"]]}`, which means she has adopted all the media files contained in event `<x>`; | ||
| 4. Now when `https://bob.blossom/<hash>` is not available anymore, clients can fetch `{"kinds":[1063],"#e":["<x>"]}` to learn who has adopted that and then proceed to look for the blob in that person's Blossom servers. |
There was a problem hiding this comment.
The whole point of putting the hash in the URL was so that when clients found broken links they could lookup the hash. looking up the event id feels even more brittle
An idea to be ruminated:
https://github.com/fiatjaf/blossom/blob/bud09/buds/09.md