Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fiatjaf
Copy link
Contributor

@fiatjaf fiatjaf commented Nov 22, 2024

Verified

This commit was signed with the committer’s verified signature.
@mikedilger
Copy link

The goal makes sense. I don't have any other particular feedback just yet.

@fishcakeday
Copy link

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.

Copy link
Owner

@hzrd149 hzrd149 left a 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>`;
Copy link
Owner

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)

Copy link
Contributor Author

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.

Copy link
Owner

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

Copy link
Contributor Author

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.
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants