💾 Archived View for bbs.geminispace.org › u › billsmugs › 5658 captured on 2023-11-04 at 16:23:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
Using the '<' as the start of the divider is a clever solution, but I'm still not sure what the gembox format gains you in exchange for the effort? I don't keep track of any file names for messages, they have the received date/time at the start of the file name to quickly sort them but when a user requests their inbox page the server just works off the list of all files in the mailbox directory.
Having a single flat file per user does make migrating to another server easier I suppose (the user can just grab all of their messages in one go and theoretically import them into another server/client), but I'm not sure that's worth having to split the file up programatically each time the user views their inbox?
In order to display a message listing, you only need to know the address you received the message from and the date/time it was received, which will always be the first two lines of the file I think? (Other instances of <,: and @ inside the message from forwards/replies etc could be handled by a client to render them differently, but they don't need to be parsed to display an inbox).
2023-09-27 · 5 weeks ago
In order to display a message listing, you only need to know the address you received the message from and the date/time it was received, which will always be the first two lines of the file I think? (Other instances of <,: and @ inside the message from forwards/replies etc could be handled by a client to render them differently, but they don't need to be parsed to display an inbox).
I don't think this is true. What I get from the examples in the spec is that the latest sender is always the last sender line, not the first. Same with timestamps. The latest timestamp is the last timestamp, not the first.
Although, it depends on if you are talking about the original sender or the person who forwarded the email to you, I suppose.
This makes sense to me because the lines are always in the order, from earliest/first to latest/last. The first sender is the first sender line, whereas the last sender is the last sender line.
You are also not guaranteed to get the timestamp within the first two lines. My current server appends timestamps after all sender lines, for example. If I wanted to switch this, then I would need to refactor my parser a bit.
As for the gembox format, it was modelled after the mbox format. mbox dates well back to Multics, probably even CTSS, well before Unix v1. I assume they chose the mbox format because it was simple to set permissions, it was just one file that had to be read, and it was fairly easy to parse, and one could move messages from/to different mbox files. It's also easier to transport mbox files. These are pretty much all of the reasons I chose to do gembox as well.
Gembox is certainly an optional thing. Servers don't need to support appending to gemboxes, so I think it's good that there are different ways of storing messages for different servers.
As for readers, supporting both individual gemmails and gemboxes allows for servers to pick and choose which they find best for their setup without worrying about hvaing unsupported readers. These two options, individual gemmails, and a flat file format like gembox, pretty much support all the options that one could need for mail storage, imo.
@billsmugs I still think you're overestimating the effort it took me to make a gembox parser. It took like 2 minutes to make, lol. I mostly just wrap around my already-make gemmail parser, detect `<=====` to split stuff, and then pass each split piece to the gemmail parser. You could probably even do what I did in even less time and with even less effort by using strings.Split in golang.
Although, you do have a point in splitting up a file each time the inbox is opened. If the gembox file ends up having like thousands of gemmails in it, then I could see how this might make it slow, but modern computers are pretty darn fast, so I'd have to test to see how slow it actually would be for big files like this.
re binary data, the spec is pretty clear that's a non starter and you should just send a link to a file.
One could always work around that restriction using base32 or base64 encoding, however.
@clseibold Having read my own messages back, I'm worried I've come across as antagonistic and/or dismissive about the gembox format, which wasn't my intention! The ease of transferring/backing up entire mailboxes and setting file permissions are definitely advantages of your system over mine that hadn't occurred to me (UNIX permissions are something I keep meaning to do more reading about in general as I know they are quite powerful but have very little knowledge of how they work and what they can do) and you're probably right that the performance impact is negligible in reality.
With regards to forwarding and sender line ordering, if Alice sends a message to Bob's server, which auto-forwards it on to me, I would expect to see the message in my inbox start with the following, with my server adding the first two lines and Bob's server adding the last two:
< b@b.com Bob @ 2023-09-27T00:00:01 < a@a.com Alice @ 2023-09-27T00:00:00
The example in the spec for sender lines omits timestamps but looks like it matches this order:
< development@mailing-lists.com Development mailing list < source@example.com Source user
I understood this as Source user sending a message to the mailing list and I then receive a message from the mailing list address.
@billsmugs I didn't read it as antagonistic, so don't worry about that :)
Also, you're absolutely correct and I misread the spec. I will have to change my server code to prepend rather than append. This is a simple change.
The thing I still have a question about is if timestamps are grouped together in reverse order like the senders are, or if the sender lines and timestamp lines are intermingled, like so:
@ Final Destination Timestamp
< Mailinglist
@ Mailinglist Timestamp
< Source user
Of if it's supposed to be more like the following:
< Mailinglist
< Source user
@ FInal Destination Timestamp
@ Mailinglist Timestamp
If it's the first one, then I will have to make major changes to my parser, because currently my parser does the second option.
Personally, I don't like that the senders are in reverse order. I feel the source user should always be at the top, not as the last sender line. For mailinglists, you want the source user as the real sender, but for forwarding emails, you want the last sender (the forwarder) as the real sender, I suppose. Hm....
In the python implementation i wrote a gembox folder class that uses the MH mailbox format. Honestly it's much nicer because you don't have to deal with indexes and stuff.
2023-09-28 · 5 weeks ago
I've got a misfin gemini frontend working where you can register, read your inbox and send messages, it was easier than i expected.
I don't like to output the cert and key in the page but lagrange has this nice feature where it parses a cert/key pair and imports it. The other way would be to have temporary (time-limited or something) URLs that let you download your certificate .. Is there any standard way of doing this with the gemini protocol ?
2023-09-29 · 5 weeks ago
Misfin Server Ideas — I believe I have written a basic solo-mailbox server in golang. It is running now, so people should be able to test it at my same misfin address (clseibold@auragem.letz.dev). I wanted to outline some ideas that I have for the server: 1. I want it to support both solo-mailbox and multi-mailbox setups. 2. An interesting idea came up when I compared the spec to gemini. Gemini has this proxy ability, I believe, so that it could actually proxy other gemini servers. This led...
💬 clseibold · 19 comments · 1 like · 2023-09-27 · 6 weeks ago