💾 Archived View for bbs.geminispace.org › s › misfin › 2742 captured on 2023-07-22 at 17:08:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-10)
-=-=-=-=-=-=-
Just read through the spec. It is interesting. I will give that it _is_ simple enough for an average developer to grok pretty easily. Unlike gemini, though, it does not seem to do much to counteract some email negatives. Ex: Since you don't need a mailserver to write outgoing mail (like smtp) it can lead to the folks writing scripts that gen a throwaway cert and spam a bunch of addresses, then gen a new cert: repeat; eventually leading to IP blocking. So we end up blocking certs and IP addresses and it mostly feels like dealing with any trad mailserver.
I _do_ think you are on to some cool stuff here and I like the direction, but would love to see more in terms of making bad actions harder.
2023-07-03 · 3 weeks ago · 👍 vladimyr
Could use the opportunity of a clean-slate protocol design to bake something like [Hashcash] into the protocol. It’s philosophically problematic for a smolweb application and I’m not sure the Hashcash scheme is appropriate without modifications, but some sort of proof-of-work scheme is an option.
Regarding hashcash, I think a problem for smolweb users is the overlap with retro/permacomputing and the love of low-power devices, enabled by the otherwise low requirements of the protocols. I hope we should be able to do something clever with identities here.
On the contrary, I think the client certificates already do a lot to improve the situation. If a piece of mail comes in with a previously unknown cert, then the receiving server can hold it, send a blank request to the domain of that cert and obtain the fingerprint. If there is no server on the other end, or no corresponding mailbox, or the fingerprint has changed, then it's spam.
In order to generate a bunch of identities, you would have to actually control the domain and be running a receiving server. Anyone attempting to spam like this would be easy to identify and that domain could be blocked. They could of course buy a new domain, or use a subdomain, but the point is that since you can't spoof a mailbox like in SMTP the mailbox has to actually exist, which makes the price for entry in the spam market much higher and also makes it easy to pinpoint where it's coming from and punish the bad actors.
This is assuming, of course, that server implementors take full advantage of the spec and do the proper challenge for new certificates.