bud09: rehosting and blob adoption

[fiatjaf]

An idea to be ruminated:

https://github.com/fiatjaf/blossom/blob/bud09/buds/09.md

[mikedilger]

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

[fishcakeday]

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.

[hzrd149]

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?

[hzrd149]

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]

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]

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]

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.

[hzrd149]

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

[flox1an]

• I don't see any harm in having both tags e and x
• Maybe we should add: The rehosting event SHOULD be posted to the same relays as the original event.
• I wouldn't distinguish between temporary or longterm types of rehosting. Everything is temporary at some point. Using the expiration tag sounds like a good idea.
• The NIP94 spec (kind 1063) does not allow for an arbitrary amount of URLs (one file + one thumb + one preview), does it? Would we allow rehosting more urls (all used in the event) or use multiple 1063 events (one for each sha256 hash)?

I had similar plans to use 1063's for rehosting but with a focus on NIP-71 videos:

1. Rehosting a missing file (1063 with x and url)
2. Allowing attachment of alternative videos to an existing kind 21 | 22 video event (1063 with e reference to the original video). This would allow other users to contribute transcoded versions that could enhance the original video event (trust / WOT required).