-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bud09: rehosting and blob adoption #39
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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