Comment by 🚀 clseibold

Sorry y'all if I miss anything or if I add things that are missed. Gemini is a pull system, not a push system, so it's a bit hard, for me at least, to have conversations like this, lol.

2024-10-11 · 1 year ago

6 Later Comments ↓

@skyjake It's no problem. Misfin(C) doesn't fix all of the spoofing stuff, but I think it does make the misfin(B) implications more explicit, imo. It could be argued that it is one interpretation of misfin(B), with changes, lol.

If you have ideas on fixing the spoofing issue that we haven't come up with, I would very much like to hear them, only because I couldn't come up with any solution that is simple/easy or doesn't create a lot of traffic.

We did discuss message IDs and senders list spoofing. For message IDs, we didn't want to add them because it added even more changes to misfin(C) and we were trying to be conservative with the changes we made. As for spoofing, we couldn't come up with good solutions.

@skyjake Note that the misfin(C) spec that mk270 created has a couple of omissions, like verification messages. I cannot upload an edited document, because satch controls the document atm. Otherwise I would have this added like right this very second, because I'm usually very impatient with these types of things.

@clseibold sorry, crossed lines of communication... I was referring to changing to "misfin:" vs "misfin://"

@johano Yeah, sorry. I misunderstood.

@satch:

How should the addresses be delimited?

Answering the original question in the thread, I agree commas are a good choice. It is consistent with mailto/email and the intuitive way to write lists (e.g., the English language).

Thank you @satch for this proposal. I've made the changes in gemalaya. I think commas for delimiting addresses are ideal.

I wonder about the format of the query string. mailto: links use named query parameters (subject=, body=, cc=, etc ..). For misfin maybe we don't really need to pass anything else than a message body in the query string ? Using named query params has some advantages if we want to pass other values in the future.

Original Post

misfin link specification proposal — So after some discussion in IRC as well as careful reading of the relevant parts of RFC 3986, here's what we've come up with: misfin:// links must not be used like mailto: links to trigger the client composing a message. This is because the // portion indicates that the address is the *authority* portion of the link, which is accurate when a client is making a misfin:// request to a server but...