and then you can read with
bm-client read -b 1 -m <uuid>
Q: i have an issue with organisations. I want to threat them a bit as regular addresses, but this has consequences in for instance the vault... One way to deal with this is that when you want to create an organisation
acme-inc, you actually registering the address bitmaelum@acme-inc!, which means that everytime we want to seek an organisation contact, we use this address. This works, but the consequence is that we might get into some issues when you actually want to use the bitmaelum@ address as an actual account.. plus, we always know that this address is valid, making it a target...
maybe we should let the user decide... for now, it only has consequences for the vault
but i cannot function with just
@bar!
Finally!
Once upon a midnight dreary, while I pondered, weak and weary,
Over many a quaint and curious volume of forgotten lore—
While I nodded, nearly napping, suddenly there came a tapping,
As of some one gently rapping, rapping at my chamber door.
"'Tis some visiter," I muttered, "tapping at my chamber door—
Only this and nothing more."
Once upon a midnight dreary, while I pondered, weak and weary,
Over many a quaint and curious volume of forgotten lore—
While I nodded, nearly napping, suddenly there came a tapping,
As of some one gently rapping, rapping at my chamber door.
"'Tis some visiter," I muttered, "tapping at my chamber door—
Only this and nothing more."
I think organizations should be treated like regular address
Since is the client the one who will register the organization address, then is the client who can modify the routing address too
Why do you think about this:
John! and john@acme! Should be treated the same (same hash function) however the organization may sign your account+routing address and provide it to you so you can register with it. The keyserver will not verify this signature, it will just store it and make it available to ask for it
John! and john@acme! Should be treated the same (same hash function) however the organization may sign your account+routing address and provide it to you so you can register with it. The keyserver will not verify this signature, it will just store it and make it available to ask for it
Then, a client who receive a mail from john@acme! Will ask the keyserver and verify the signature. If the signature is not there or is not correct then it will flag the message as “unsafe” or something like that so the client will know that despite the address looks like comes from an organization, it actually won’t
It’s easier to implement (no work for the keyserver) and easier to create and maintain organization addresses
What do you think?
BTW we should move out from Gitter. It sucks XD
BTW now that I re-read the email I sent you it sounds like I’m proposing lol
but i don't know what else.. problem is that i really like the history at the moment for finding solutions to problems..
so... if I have "john!", then "john@acme" and "john@wick!", and "john@bonjovi!" should be the same users?
i would see organisations as a namespace, more or less.. where no namespace is the default namespace...
Sha256(“John”) != sha256(“john@acme”)
that can only come from the organisation itself
You are thinking that because the address has a @ in it it should belong to an organization. But what I’m telling is that the @ means nothing, only visually it could belongs to an org, but in reality anyone could create that address. Only the address that cryptographically are signed are the ones that belongs to the org
we don't need to check it every time?
The client will verify when receive an email from that account
And will add a flag to the email telling that the email comes from an organization (and the organization name)
More IKEA furniture 😅
send you a new message...