Skip to content

bud09: rehosting and blob adoption #39

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.

Sign up for GitHub

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

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

bud09: rehosting and blob adoption #39

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions buds/09.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# BUD-09

## Rehosting or blob adoption

`draft` `optional`

Defines a Nostr event for announcing that a file is being rehosted on some other server or that it has been adopted by some other pubkey.

### Adoption

Adoption means the act of declaring that one also intend to keep hosting a file in their Blossom servers.

For example:

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>`;

@hzrd149 hzrd149 Nov 23, 2024

Copy link
Copy Markdown
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)

@fiatjaf fiatjaf Nov 24, 2024

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

@hzrd149 hzrd149 Nov 26, 2024

Copy link
Copy Markdown
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

@fiatjaf fiatjaf Nov 26, 2024

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

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.

@hzrd149 hzrd149 Nov 23, 2024

Copy link
Copy Markdown
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


### Rehosting

A more flexible approach means not committing to hosting a file forever, but only giving users a second choice in case the first server is unavailable.

For example:

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 some public server and paying for its storage out of her pocket for a couple of years: `https://public.blossom/<hash>`;
3. After uploading it, `alice` can publish an event `{"kind":1062,"tags":[["e","<x>"]],"content":"https://public.blossom/<hash>"}` and forget about it.
4. Now when `https://bob.blossom/<hash>` is not available anymore, clients can fetch `{"kinds":[1062],"#e":["<x>"]}` to learn who what other server might be storing the same file.