i2p.i2p-bote Mailing lists (Trac #1467)

It would be very nice to have mailing lists for Bote.

Migrated from https://trac.i2p2.de/ticket/1467

{
    "status": "assigned", 
    "changetime": "2017-01-15T13:55:14", 
    "description": "It would be very nice to have mailing lists for Bote.", 
    "reporter": "user", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1484488514377592", 
    "component": "apps/plugins", 
    "summary": "Mailing lists for Bote", 
    "priority": "minor", 
    "keywords": "I2P-Bote", 
    "version": "0.9.17", 
    "parents": "", 
    "time": "2015-02-08T22:32:11", 
    "milestone": "undecided", 
    "owner": "str4d", 
    "type": "enhancement"
}

Apr 16 '17 23:04 str4d

Trac update at 20150209T03:58:58:

str4d commented:

Are you suggesting that mailing list software be added directly into I2P-Bote, or that regular mailing list software should be usable with I2P-Bote?

I would be more interested in the latter, because I expect that the API additions to support mailing lists would also benefit any other online system that hooks into emails. How does existing mailing list software receive emails? Sending is (I expect) done via SMTP, and I2P-Bote already handles that.

str4d changed keywords from "Bote" to "I2P-Bote"
str4d changed status from "new" to "infoneeded_new"

Apr 17 '17 00:04 str4d

Trac update at 20150209T09:56:12:

user changed _comment0 from:

i actually meant the former. Sending a Bote mail is slow and hence sending a mail to let's say 100 people takes considerably more time than sending a mail to the mailing list.

to:

1423477715759988

user commented:

i actually meant the former. Sending a Bote mail is slow and hence sending a mail to let's say 100 people takes considerably more time than sending a mail to the mailing list. implementation should be rather easy.

user changed status from "infoneeded_new" to "new"

Apr 17 '17 00:04 str4d

Trac update at 20150209T10:29:03: user changed keywords from "I2P-Bote" to "I2P-Bote, easy"

Apr 17 '17 00:04 str4d

Trac update at 20150218T05:17:21:

str4d commented:

Sending Bote mails is intentionally slow, to inhibit spamming. But more generally, Bote treats all sent emails as unsolicited, and therefore the mail must be sent individually to each recipient, because there is no cryptographic connection between the recipients. Perhaps a later protocol revision could enable !EmailPackets to be encrypted to multiple recipients, but that makes deleting !EmailPackets trickier. And anyway, it would make spamming much simpler.

However, mailing lists inherently have the recipients' permission to send emails to them, via an explicit subscription process. If during that subscription process the recipient provided some token or shared secret, then the mailing list could use this to enable the recipient to read the ML posts. Users would send ML posts to the Bote Destination of the mailing list, which would then resend them to the "shared mailbox" for all subscribers to download. Subscribers would then check the shared mailbox for new ML posts. There could be an option to auto-resend or not, which would allow moderation of a ML.

This would require a new type of !EmailPacket that allowed multiple recipients to decrypt it, and that was deleted only after all recipients had sent a delete authorization, as well as a new type of !IndexPacket that could index the new !EmailPackets. Basically, it would require everything I mentioned in the first paragraph, but mandating recipient participation, which would prevent spam.

One concern I have is that the functionality of the mailing list operator is so divorced from regular Bote that I don't have a good sense of how the UI would work. I wonder whether this kind of system would be better implemented in a separate plugin, that uses the same backend Bote code but has a completely separate frontend specific to mailing list operation.

The downside of this is that operating a regular Bote client and a Bote mailing list would involve two separate Bote network nodes on the same I2P node, which wouldn't be impossible but would increase load on the server (and double the user's participation in the Bote network). The upside is that there would be a clear separation of concerns, and the UIs could be tailored specifically to their intended users.

While writing this, I also wondered whether the mailing list design/mechanism could be generalized and decentralized to allow "group mails" where users share a secret between themselves and then send mails to a centralized mailbox. This would remove the need for one Bote node to administer the group, but would also remove the ability to moderate the group (which is not usually necessary for small groups, but can be for large mailing lists). The process for adding and removing users from the group would be much more difficult too.

All in all, this ticket needs considerable research and design before anything would be implemented. So while I think your idea has merit, I don't think it qualifies for the "easy" keyword :-P

str4d changed keywords from "I2P-Bote, easy" to "I2P-Bote"

Apr 17 '17 00:04 str4d

Trac update at 20150218T15:18:18: user commented:

mailing list:

a ml is a shared keypair (no deniability as it is public) with special treatment. -- pubkey as the address where you send your messages, and privkey to decrypt what others have sent there. -- optionally ignore mails with ml address as sender and those that come without any sender at all. -- restricted access: a pre-shared changeable nospam value, checked by client. -- ml messages need special treatment of not being deleted after having been read. -- subscribing to mailing list, means adding the keypair in a mailing list section in bote.

Mailing lists

all participants share a keypair.

messages to the mailing list are sent to its normal bote address

messages to the mailing list are sent from one of the user's normal addresses (i.e. signed with their own priv keys), a throw-away address, addressless (anonymous) or using the mailinglist's private key.

all subscribers retrieve and decrypt the messages with the ml private key

messages are not deleted from storage nodes after retrieval

decentralized, unmoderated, no central authority

vs

moderated mailing lists:

there is a central authority (ca) - normally a user, but it can also be more than one

ca is is in possession of a keypair (a normal bote identity).

all share the pk tho which the mails are sent.

allowed mails are then sent by ca via subscription (#42) to all other users

Apr 17 '17 00:04 str4d

Trac update at 20150218T17:56:52: user commented:

that would be the easy approach to it, that I had in mind. Therefore the 'easy' tag. It would only need minimal changes to UI and minimal changes to backend. For storage nodes only the deleting part changes, for relays nothing. Storage-wise it would be the same as sending a normal bote mail to an inexistant or never retrieved address, so no really big increase either. spam control in unmoderated lists could be done locally with black or white lists or the nospam value.

Apr 17 '17 00:04 str4d

Trac update at 20150915T07:11:54: user commented:

This would be good for UX and for the network.

Imagine someone wants to set up a mailing list. Let's say 20 people participate in it, then every mail must be sent 20 times. If at least one of those users does not check his mail anymore, the mail will remain for maximimum storage time in the DHT AT LEAST once.

With mailing lists it will remain for maximum storage time ONLY once. And it will be sent only once. A mailing list is like one user, so it has benefits for the sender and the network.

Apr 17 '17 00:04 str4d

Trac update at 20170115T13:55:14:

zzz changed owner from "" to "str4d"
zzz changed status from "new" to "assigned"

Apr 17 '17 00:04 str4d