BUD-10: Implement 'user backup lists' tag

[dtonon]

I'm going to release an update for Chronicle that supports backup of others' blobs, to have a really full copy of the conversation where the owner participated, media included.
If the original author of a note doesn't offer working backup locations, we risk being unable to retrieve their media. With the fallback tag the user can instruct the client to use some preferred additional servers, before falling back to the "well-known popular Blossom server" as a last resort.

[hzrd149]

If I'm understanding this correctly the fallback tag is supposed to be used by the client to find blobs from other users one all the servers on the other users 10063 have been tried.

If thats the case then I don't think it makes sense to add this to BUD-03, it seems highly specific and something that the application itself should store, since its user configuration
Also as BUD-03 is now it only keeps an ordered list of the pubkey's blobs, expanding this with more server configuration would get more confusing for clients

[dtonon]

I agree, it's better to move all this stuff to a new kind.
I will push an update asap.

[dtonon]

Pushed a new BUD-10 to manage user backup lists.

@fiatjaf FYI

[dtonon]

I'm not sure if listing more URLs for the same p / e tag is fine, or it would be better to duplicate the tag.

[dtonon]

@hzrd149 have you had a chance to review the PR?

[hzrd149]

I'm not sure if listing more URLs for the same p / e tag is fine, or it would be better to duplicate the tag.

I wouldn't include the blossom server URLs in the p and e tags. traditionally those are for nostr hints and if I'm understanding things correctly the server tags should be enough

[hzrd149]

Besides removing the server url from the p and e tags I don't see any issues. but the more I read the more confused I get. I don't understand what this is for? is it supposed to be a better way for users to find blobs once they have been lost?

[dtonon]

I wouldn't include the blossom server URLs in the p and e tags. traditionally those are for nostr hints and if I'm understanding things correctly the server tags should be enough

You are right, the URL position is confusing, we should use the next free position (5th for e and 4th for p).
But they are needed, the server tag is a fallback if you omit the URL in the p / e tags, action that could be wanted to reduce the event size if the server is always the same (how often will happen).

I don't understand what this is for? is it supposed to be a better way for users to find blobs once they have been lost?

Yes, it's a way to share your backup (or any other know backup) to permit users to access blobs from other authors that are not anymore available in the original location.
My Chronicle relay could generate this event once at day/week.

[hzrd149]

You are right, the URL position is confusing, we should use the next free position (5th for e and 4th for p).

We shouldn't be overloading the e and p tags. they already point to an event and a user with an optional relay hint and now we are going to add an optional server hint? how is anyone supposed to parse this?

My Chronicle relay could generate this event once at day/week.

What would an example event look like. the way the spec is written the event is very flexible and could mean anything from "I'm backing up all the users blobs here" or "I've saved this one video from this note here"

Also if the goal is to produce these weekly how are client supposed handle duplicates? or worse incorrect kind:63 events?