am I flying too close to the sun with this idea
alright, going to start on this project. with family this week so probably won't be able to do much for a while, but I think there's something here
@aw I approve of flying too close to the sun.
- Write out why not multiple recipients: otherwise it's the first thing people will want to add.
- Write out why no envelope for binary blobs: otherwise it's the second thing people will want to add.
- Write out why gemtext: otherwise people will want to extend it, add Markdown and AsciiDoc and HTML support and mimetypes, and...
- Write out why no TLS or other handshake.
- Address format should probably not look like email?
@aw It seems to me the GETKEY should also validate that the content is correct, not just user.
Like: SEND says "hey, firstname.lastname@example.org has mail for email@example.com, subject this, body SHA1 is this", after which demo.site can do a FETCH of that from example.com.
So spam DNS "proves" it actually comes from alice, and receiver doesn't have to store bodies from unknown senders until human decides to read them. (This should not be considered a "read" receipt!)
...and you can batch those FETCHes.
@aw Uh. I know you're going to hate this (I kinda do...), but doesn't this (idea of send+get something) map directly to POST and GET.
Is there actually a benefit of using a custom protocol instead of stuffing this into HTTP?
@nikodemus same reasons as gemini basically
1. http is really complex
2. http is overloaded to do basically everything these days
3. I like the novelty of non-HTTP protocols: novelty that has basically been lost. think https://en.wikipedia.org/wiki/DICT
4. allows server to run on non-privileged ports
5. this is basically a toy. it isn't meant to "solve" email in any practical sense (that would be impossible)
@nikodemus don't see any reason this needs to be in the spec. bandwidth and compute is cheap, just truncate it if you need to.
@nikodemus this verification wouldn't be dns based. an email from example.com would have to be from a server that runs on example.com at port 1999. this simplifies things. I talk about this very briefly in the doc
@c__pnk Iol I’ll credit the twinmail folks in my spec!
I haven’t checked on the discord in a while, but I think my design vision differed with the chat a bit
you seem to have a better sense of structure though... what if we combined the two somehow? or not. just thinking out loud. I think the encryption is pretty important for something like this.
@c__pnk I'm not sold on the importance of e2e encryption in a lot of cases, but it may be part of the spec. still need to flesh out these ideas into something comprehensive though
@aw you know.. i opened up the code just now and felt the same way. is there somewhere i can chat with you in real time? i might just abandon twinmail and make like an easier pgp to use in-hand with nanomail.
@c__pnk discord works for me, but I think that my proposal is a bit immature at the moment. Give me a bit to get something a little more fleshed out that we could discuss
Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.