-
Notifications
You must be signed in to change notification settings - Fork 577
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
Comments
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." |
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! ;) |
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. |
Meh, probably not worth the trouble: mailing lists seldom call for the It's not as l33t as using raw binary for the message format as you But yea, even this simple level of functionality would be very |
Hi cathalgarvey, 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 |
worked on implementing loader popup functionality on account switching
implemented address disable feature or fixed issues
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. :)
The text was updated successfully, but these errors were encountered: