> Have you considered using extended file attributes for metadata? 
> Extended
> attributes exist exactly for this kind of use case.

We discussed this previously, but ~bitfehler argued against it because of 
uncertain platform support.

https://lists.sr.ht/~bitfehler/m2dir/%3C17c32401239f7b0b.f35d3f6599202235.cdc008ecf268f5a1@mba%3E

> One thing that strikes me as very weird though is the unique-id,
> not only it's way too short 2^12 = 4096, I think it's reasonable
> to expect more emails than this.

The hash is 12 bytes, not bits. 2^(8*12)≈8e28 which should be big enough.

Wow, you're on top of it Clément! I just sent you an email mentioning
m2dir to you and here you are beating me to it.

For your information, I've begun a pretty serious attempt at writing a
library myself: https://git.sr.ht/~kmaasrud/m2dir-rs It is pretty much 
ready for use already, just lacking a few functions and proper testing. 
Also ~bitfehler has his own library that he has been testing with, 
though he has mentioned that he deems it a bit messy because it was 
written along with the spec.

-- 
Magnus

> Not entirely sure about the must -> strongly recommended part. I mean, 
> this is getting a bit philosophical, but even if nothing _reads_ the 
> file, it's still fair to say that an application creating that file 
> _must_ keep it empty, to not mess with potential future extensions?

That is true, but then a future version of m2dir that has something in 
the dotfiles would not be backwards compatible. By using STRONGLY 
RECOMMENDED, we don't need to break compatibility if something like this 
is added in the future.

Say, m2dir 1.0 STRONGLY RECOMMENDS to keep the files empty, but an 
application that supports it chooses to put some random data there. m2dir 
bumps to 1.1 and adds a version tag in the dotfiles. That application 
broke the recommendation and is therefore limited to only supporting 1.0.

From: Knut Magnus Aasrud <km@aasrud.com>

Signed-off-by: Knut Magnus Aasrud <km@aasrud.com>
---
Since applications MUST merely check for `.m2dir` and `.m2store`, we
can only STRONGLY RECOMMEND they keep them empty. Also, I think it is
worth rephrasing a bit to clarify that this is in the name of forward
compatibility.

 index.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.md b/index.md
index d589623..1ceb996 100644
[message trimmed]

> Here is what I'll do: my Mondays are always really busy, but I should 
> manage to publish an update to the spec on Tuesday that incorporates 
> all the things we hashed out in this thread. I'll also push the code 
> someplace for you to see by then.

Great stuff, but don't feel any obligation to rush. We all have busy days 
at work and such, and this is all fun!

> [...] it might of course be fun to see with what kind of API you'd come 
> up with with a green-field approach. Just a thought, though, I'll leave 
> that up to you.

I'll try to sketch out an API that would make sense for me, and we'll see 
if it holds up. Maybe a merge of the two would work well, let's see!

> The spec is intended to give enough leeway that changing the 
> human-readable part is possible, but I would say it should be 
> discouraged. At the very least, it would always have to happen with 
> explicit consent from the user, so that any index or such could be 
> re-built.

That is a very smart recommendation for implementors!

> Other than that, I think renaming _should_ not happen. Since you're 
> asking about this, you probably have some use case in mind, though, 
> right? I'd be curious to learn what that is :)

No, just curious. I think I, and most users, would not really touch the
m2dir files that much, but it is nice that it is allowed.

As discussed, here are some of my thoughts on the spec: After having 
read through the spec, I generally think this is an improvement on 
Maildir in almost every way. I feel like you've hit a sweetspot between 
keeping things simple while still allowing some flexibility in the spec. 

> Each message is a file, with an immutable name

Why immutable? I get that the hash should be immutable, but is there a
good reason for requiring this for the human-readable (or any other) 
part as well?

> Depending on the setup, an m2store root may itself be an m2dir.

Given the fact that this is not allowed when mirroring an IMAP (as you

> Thanks for reaching out! I have in deed been working on something for a 
> while now, but as always got sidetracked by a bunch of other stuff. So 
> I don't consider it done, but while I didn't "publish publish" it yet, 
> I did publish it as "unlisted":
>
> https://sr.ht/~bitfehler/m2dir/

I just did a quick read-through, and this looks very close to what I've 
always wanted Maildir to be. Super thorough work!

> I would be very interested in your thoughts.

I have some thoughts already. I'll share my thoughts on the m2dir list as 
soon as I get home from work.

I just read your post on the Maildir spec, and it really caught my 
interest. I am writing a command line MUA and although I'm trying to be 
pragmatic about using Maildir++ because it's so widely supported, I've 
been facing exaclty the same issues as you.

You said that you were working on some new spec yourself? What's the 
status on this? I would definitely be interested in helping out!

-- 
Knut Magnus Aasrud