đž Archived View for bbs.geminispace.org âē u âē clseibold âē 20715 captured on 2024-12-17 at 15:26:12. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "misfin link specification proposal"
If we care a lot about spoofing and encryption, then LATSSIAM is another protocol mk270 designed that I think takes these things into account much better, afaik. It might be worth looking at.
However, LATSSIAM is much more complicated because encryption can be complicated, especially if you are dealing with verifying every single header line (not sure if LATSSIAM even does this). Not even regular email does this (although, yes, regular email is a very low bar when you can barely even verify the last sender, lol).
I agree with satch. Recipients lines are hardly a problem, imo. A person could include a recipient to one person of a group, but not the other, but then that second person wouldn't reply to the included person. If a recipient is added to a group email for everyone, then everyone can see it.
As for senders and timestamps: verifying the existance of mailboxes is easy. Verifying that a mail was actually sent by that address is much harder, and could create a lot of complicated network traffic and significantly increase the complexity of implementation, imo, because now every single server that receives a mail has to send to every server in the headers asking if they sent a mail. That increases exponentially! Yikes!
But also, we have no way of identifying mails either, because there are no message ids. So how would we ask servers that a mailbox sent a mail? So we need to now add that. This also means these servers have to now keep track of every sent mail.
There could be a way to simplify all of this with encryption, however, which is why I suggest looking into LATSSIAM.
Oct 11 ¡ 2 months ago
đšī¸ skyjake [mod...] ¡ Oct 11 at 14:57:
Thanks @satch and @clseibold for the further clarifications. I must admit my thinking was centered very much around Misfin(B) and I had not fully realized that the Misfin(C) draft addresses much of this already. Apologies!
I will need to fix Lagrange so that it follows the C spec correctly and includes the mandated three metadata lines in the message. This is not done currently. (Lagrange only switches to C when the content is too long to fit in B.)
đ clseibold ¡ Oct 11 at 14:58:
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.
đ clseibold ¡ Oct 11 at 15:00:
@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.
â Misfin C Change Reasonings Document
đ clseibold ¡ Oct 11 at 15:46:
@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.
â¯ī¸ johano ¡ Oct 11 at 16:05:
@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).
đē gemalaya ¡ Oct 18 at 16:17:
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...
đŦ satch ¡ 27 comments ¡ 3 likes ¡ Oct 10 ¡ 2 months ago