So, we’ve all been there. We download an app and months later after forgetting even the name of this app, we continue to receive emails about the latest features or what they plan to release as features in our mailbox. When we get bored of individually deleting these emails(or worse the spam marketing you never cared abt), we see the ever illusive caption:
We’ve now got the option to literally go to the company/spammer that’s been annoying us and request, well that they stop annoying us. Sometimes we even need to log in and prove it’s us before doing so and of-course by this time, we’ve forgotten any credentials we might have had. So it starts off with a password reset, followed by a new email confirmation and then back to unsubscribe and a message saying “You’ve successfully unsubscribed”
That’s pretty much a crappy process.
- Why is it that when we the consumers want to not be spammed, we need to “request” not being bothered from the same people that are causing this nuisance?
- Why can’t spammers ever be the ones to care more about their inbox than the end users?
- What’s the guarantee that unsubscribing really gets us unsubscribed from our spammers?
^^ All valid questions :). So when @dirvine & @Fraser walked into the office on Thursday and said “Viv you want to hear this out. Think we might have a neat solution for mail spam.” I was more than interested to hear them out. Currently in the SAFE network when your MPID(your public id’s) send messages to another public Id, they travel to the recipient via his close group and if they are not online, the message stays with the recipients close group until he comes back online. When the user gets back online, he gets a few notifications with all these offline messages.
What David proposed here was to not send these messages past the sender’s close group(got your attention yet?) and in it’s place only send a tiny packet notification(by tiny we mean reallyyyyy small) to the receiver informing him “You’ve got mail”. Now if the receiver has not blacklisted the sender the actual mail is retrieved by the receiver’s close group else the sender is paying(via space) for these mails clogging up his mail quota. Now any user’s said outbox is a fixed size(prolly variable by rank and sorts. Let’s skip details right now). So if a user is not online to receive his email’s or if he “blacklists” a sender, they end up never actually getting mails from the sender instead of a masked Junk folder. Tricky bit here is when the receiver blacklists the sender, his close group will silently drop the notification packets from the sender thus intentionally causing the sender to end up with a clogged up outbox. The sender needs to now ensure he doesn’t end up spamming himself(ah times have changed) which is going to block him from sending any new mails once full. If the recipient was offline when the mail was sent to him, he still gets notified of this action and the message is retrieved by the network for the recipient if the sender wasn’t blacklisted.
It’s great that blacklisting a sender here is only at the recipient’s side, but still impacts the spammer. He doesn’t have to go to the spammer and ask him to play nice. He really just deals with his own inbox and the network takes care of the rest. Kind of starts showing the power of the SAFE network to be unique than a copy of today’s internet. As a spammer, ah well sucks to be you I guess
There are quite a few ways this helps App dev’s making mail clients spend their time in app features than deal with the sheer handling of spam for their user’s let it be via Junk mail folders, mark as Spam, signing up to services to unsubscribe from Spam.
- Mail client’s can now even try to synchronize say blacklists across friends/family to more effectively block spammers before a user is affected directly.
- If a normal user does get a clogged outbox (too many recipients off-line) their apps can take the message back and resend it when that user speaks to them, or simply retry after an interval. If spammers pretend to act like normal users, they then need to pay attention and behave exactly like one at which point they become a user
This is like the personal ranking/rating mechanisms discussed in the forum, but is real-time and individual, which is great as the network does not need to calculate a persons rate, but the network members do so in real-time. This is possible in the SAFE network as close-groups have this authority to manage nodes and they are not owned by any entity, except maths. We can surely expect to see some more very surprising uses of this as we roll the testnets out. This is an important design pattern in truly decentralized networks.
If you’ve read this post until this point, I’m sure your next question is “Great. When can I have this already?” which would definitely be replied with “Patience pls :). This is an idea that needs to get implemented in the system libraries and should make it’s way to the testnet’s. You guys will definitely hear more about it’s details as it gets implemented and can track/contribute to the process via JIRA”. You can also check the work going into the MPID - Design Docs.