Opened 7 years ago

Last modified 4 years ago

#1467 assigned enhancement

Mailing lists for Bote

Reported by: user Owned by: str4d
Priority: minor Milestone: undecided
Component: apps/plugins Version: 0.9.17
Keywords: I2P-Bote Cc:
Parent Tickets: Sensitive: no


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


Change History (9)

comment:1 Changed 7 years ago by str4d

Keywords: I2P-Bote added; Bote removed
Status: newinfoneeded_new

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.

comment:2 Changed 7 years ago by user

Status: infoneeded_newnew

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.

Version 0, edited 7 years ago by user (next)

comment:3 Changed 7 years ago by user

Keywords: easy added

comment:4 Changed 7 years ago by str4d

Keywords: easy removed

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

comment:5 Changed 7 years ago by user

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


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 (#1468) to all other users

comment:6 Changed 7 years ago by user

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.

comment:7 Changed 6 years ago by user

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.

comment:8 Changed 5 years ago by zzz

Owner: set to str4d
Status: newassigned

comment:9 Changed 4 years ago by str4d

Migrated to - I will close these tickets as things are resolved rather than right now, but please make future comments on GitHub?.

Note: See TracTickets for help on using tickets.