💾 Archived View for bbs.geminispace.org › u › clseibold › 20720 captured on 2024-12-17 at 15:26:15. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "misfin link specification proposal"
@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.
Oct 11 · 2 months ago
@clseibold sorry, crossed lines of communication... I was referring to changing to "misfin:" vs "misfin://"
🚀 clseibold · Oct 11 at 16:20:
@johano Yeah, sorry. I misunderstood.
🕹️ skyjake [mod...] · Oct 11 at 16:24:
@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.
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...