Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: "Mailing List" Addresses #51

Closed
cathalgarvey opened this issue Feb 19, 2013 · 5 comments
Closed

Feature Request: "Mailing List" Addresses #51

cathalgarvey opened this issue Feb 19, 2013 · 5 comments

Comments

@cathalgarvey
Copy link
Contributor

Hey, I'm not sure how hard this will be to implement but my hunch is "not very". Still digging into the codebase and trying to figure out how it all works.

Anyway; Bitmessage has support for broadcast addresses that people can subscribe to, which can also receive mail as normal addresses.

If there were an action-hook for addresses to call as they receive mail, then one could configure an address that auto-broadcasts any message it receives, creating a mailing-list address. If sender's addresses were included by default (at mailing-address-owner's option), it'd behave like a normal list. If not, then it'd be a sort of anon-list, where senders choose whether to include their address/id in their signatures.

This feature would really expand my ability to sell bitmessage to others, and it would provide an easy-in to new people to bitmessage: join bitmessage and discuss it internally on the bitmessage network, rather than on the subreddit or public forum!

Anyways. I'll keep digging in my spare time and perhaps I'll find a way to implement this. It would be doable with an RPC interface too, of course. :)

@Atheros1
Copy link
Contributor

I don't think it would be very difficult. For the interface we could add an option in the context menu when you right click an address which says something like "Special address features" which brings up a form to allow you to turn on an option: "When a message is received at this address, broadcast it for everyone to see."
There could also be a sub-option: "Include the sender's address in the broadcast message".
Adding this feature will, of course, make people want a richer management interface including user rights management.

@cathalgarvey
Copy link
Contributor Author

Sounds good, can't wait to see!

One thing I discovered while investigating this myself is that there's a falsification detection system baked in to prevent malicious message re-sending from a new address.. that's great, but it won't play well with a mailing list, unless messages from broadcast addresses are auto-whitelisted for this sort of "attack", so users instead trust the signature from the sending key (if available) and not the broadcast address.

But then, you'd understand far better than I how that system works! ;)

@Atheros1
Copy link
Contributor

Indeed, all messages would appear to come from the broadcast address no matter what- they would never come from the sender's address. The "Include the sender's address in the broadcast message" option would do nothing more than put in a line at the top of each reply: "Message rebroadcast from BM-BasLdoAsomethingsomething". You could trust this line to be truthful as long as you trust the owner of the Broadcast address. I don't think it is very important to authenticate since it is meant to be a public mailing list anyway. I suppose we could include signatures to authenticate the original sender without having to trust the broadcast address owner but then we have two layers of signatures and the program definitely isn't set up to do anything like that right now.

@cathalgarvey
Copy link
Contributor Author

Meh, probably not worth the trouble: mailing lists seldom call for the
same level of authentication and verifiability, and that level of
code-refactoring would be a needless distraction from more important tasks.

It's not as l33t as using raw binary for the message format as you
appear to, but I'd have personally loved to have JSON-formatting of
messages, for this sort of reason; could nest original messages within
the JSON field for the broadcast message, and just code the client to
present nested messages with appropriately nested authentication, or
something. It's more flexible, but at cost of being harder to manage in
C, I guess (should someone code a client in C).

But yea, even this simple level of functionality would be very
excellent. I'm imagining a near future when I can "mirror" mailing lists
I like within bitmessage, and vice versa, to reach a broader/more
paranoid audience!

@Atheros1
Copy link
Contributor

Hi cathalgarvey,
The format of messages is something that can be decided on by defacto community action- messages each contain an 'encoding type' which is just a number that ranges from 0 to [really huge]. The first 3 are defined but other people are more than welcome to come up with their own ways of encoding messages and I'll support whatever people want.

Concerning pseudo-mailing lists or subscriber lists or whatever people want to call them, I have implemented the feature and it is now active in v0.2.6. Just right click on one of your addresses.

Atheros

henrikolsson pushed a commit to henrikolsson/PyBitmessage that referenced this issue Nov 9, 2015
PeterSurda pushed a commit that referenced this issue May 2, 2016
surbhicis pushed a commit to akeelahmedqureshi/PyBitmessage that referenced this issue Dec 19, 2019
worked on implementing loader popup functionality on account switching
surbhicis pushed a commit to akeelahmedqureshi/PyBitmessage that referenced this issue Mar 18, 2020
implemented address disable feature or fixed issues
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants