We just today had several discussions on the implementation of the Public Messaging system for the SAFE network. Already one of the key features is that a message sent, is stored at the responsibility of the sender: until the receiver actually wants to retrieve the message (she gets an alert), the sender has to store the message. One motivation for this is to re-institute the cost for potential spammers - the burden is on the spammer to clean his outbox, rather than all of us cleaning our inbox.
Maybe though, this design choice by David, goes even deeper. I just watched this video:
Iâll summarize it in two points I took from it:
between offline and online, maybe we should consider the in-between state of âfocusedâ. The sender can send his messages, but is aware the receiver is currently focussed. They will be delivered later, unless he actively chooses to interrupt the receiver because it is urgent.
measuring performance not in usage, but in net positive result, which is the total positive human result minus the investment cost of having spent time with the technology. (watch the video to make this more clear).
The first point we could very easily integrate in the SAFE network at the lowest level, available to all apps. Every SAFE app would be in the same âfocusâ mode. Comments?
The second point is mostly for internal MaidSafe consideration: what measures do we have to measure the net positive value we are creating with our technology?
Has it been discussed if there is some way to make plain-text messaging free? In terms of bandwidth plain-text chat should be negligible. I understand currently the SafeCoin costs will also be negligible, but I think the psychological factor of it not being completely free matters a lot. New users that wouldnât have any SafeCoin yet are also currently excluded from messaging. In addition, people are used to free messaging services. For example, I can use Telegram for peer-to-peer encrypted messaging on my smartphone, for free (granted, they still steal my contact list info).
The challenge is of course to counter abuse. Quick brainstorm:
Perhaps messages that can be instantly delivered could never be stored on the network?
Routing such messages could be a voluntary activity of the managers. Using too much bandwidth could result in routing refusal that way.
A limited bandwidth could be provided for free to every user, enough for plain-text messaging.
But, perhaps these ideas are not possible because messaging is being build as a layer on top of the PUT/GET system, not next to it?
Interesting points, messaging is actually parallel to put/get in the code. We do not use the put/get machinery so this is possible. We have done a neat trick here, messaging is free, but limited. So the outbox will fill if no messages are read be recipients (it will take many messages to fill). This means the cost is network limitation. Its like we are the postman and refuse to hold a ton of mail for you (the spammer pattern is to send a ton).
The idea is to charge some safecoin, its not fixed though, it may be good to not do that. The other issue I think is we can blacklist (people can choose to use their own blacklist/whitelist) to quiet the system for them. The issue is limitation though, if creating accounts is dead simple then all the anti spam measures start to fail a bit. Spammers will keep creating new accounts.
We can have network reputation where people decide they got spammed and the network notes that and can report it to all other users. So you could set your mail to not accept new contacts who have a rejected score of 50% say? It gets dangerous though and does take a lot of poking around the edges as nearly all of this has side effects that tend to do the exact opposite of the intent.
Making the cost so tiny that it is practically free for regular use may be a good compromise.
I understand the profile for spam is a target response of about 0.01% or something silly. Therefore they need to send tens of thousands of emails just to make it worthwhile. If there was a fraction of a penny/cent (say, 0.01 %) most people would never notice the cost, but would recognize the lack of spam.
In short, sending 100k emails would cost a tenner and may only get one bite from a recipient. Worth spamming for that? Probably not.
The question is not easily answered and quite paradoxical. There is no lack of marketing with a budget, so messaging with a small cost per message, is still not what we might aim for.
The idea David offers of a limited outbox is nice. We put the burden on the sender, but equally if someone sends out millions of messages, but all those millions of recipients WANT TO READ this message, our sender should not have problems, and can do so for free. That is because all his readers will keep emptying out his outbox as they choose to read this message.
However, if you start sending messages that donât want to be read, they will linger in your outbox. Either you delete them from your outbox - and hence also from the recipients inbox; or your outbox will fill up and you canât send more messages. (Just like in the old days you couldnât receive new mail messages anymore when your inbox was full.)
So we might actually get it right by having free messaging. If you store big attachments as chunks on the network, then of course normal PUT charging will apply.
Is this not going to have the same problem of multiple account creation though? That is, multiple out boxes on multiple accounts.
I like the idea and it is something made possible by the technology being implemented (beyond what email can do), but I wonder whether a minimum charge is the only real solution for the bulk of spam.
This one will be interesting to watch, the multiple accounts thing is indeed an issue, but for more than this. I feel we will address the multiple accounts in a way that covers all use cases of account manipulation.
So yes multiple accounts is an issue, but elsewhere to, I think its a fixable thing and more as a fundamental thing as opposed to messaging. This is what we do, try and drive the issue to its fundamental type and make sure that type is really a fundamental one. By that I mean the fundamental (near concrete) type should be really so simple it is laughable and entirely obvious, getting there is the hard part though we always do though.
I do not mean to cop out here, I think there are a few areas like multi account, vault manipulation strategies etc. that can all be overcome, but do not necessarily have to be immediately (launch first) and these will be addressed properly with more eyes and less pressure. So for the time being we can use sticking plasters (add in if(paid) { âdo stuffâ } etc.) but we have found these cause information cascade in the code and end up as monsters (lots of conditional code appears and it grows, showing an issue in fundamental algorithm is wrong).
I have been far away from code for the last few years and now back at the coal face and we have had a few of these âinformation cascadeâ issues as a simple âlets put in an if statement and make this happenâ or âlets use this other thing out of context to achieve this other thingâ and they have bitten.
So for me it is get the core core parts solid and where it will take too long, get a simple thing that will work and follow the desired goals and fix properly the other parts (multi accounts in this case) as a proper mini project.
Sorry man, I went a bit typing mad there, not gonna even try and count the dirvine grammar issues in this one (donât look back I say)
BTW happy holidays to everyone, its a great time to get your head into interesting stuff, have a great one everyone!!
I hear what you are saying. You donât want to be designed code with additional checks included which are intended for elsewhere. You just end up with a web of tangled logic.
I have become a big fan of the SOLID principles and they are a good foundation. If a class is doing more than it is intended to do, something needs refactoring!
Happy Christmas to you and everyone else involved in the project. Keep up the good work!
Yes thanks for that, I re-read what I wrote and worried a little it came across wrong, glad it did not, I love learning and differing opinions. Anyway yes SOLID is great a good reminder. I intend to read Stepanovs new book over this period if I can get routing_v2 complete and linked to nfs and vaults. Yip optimist for sure, but its good to read from deep thinkers, it reminds us to think.
I think the reason why spam is effective on for example e-mail, is because the spammer can shove the spamâs title in everyoneâs face, thereby catching at least the interest of some people. By first having a choice whether you even want to see anything at all from someone, I think spam loses most of itâs effect.
That being said, I think the spam problem should not be tackled at the core level. For example, it should be possible at some point to make a spam filter mechanism (app) in MaidSafe as a community effort. People could report spam accounts through that mechanism and get a small SafeCoin reward from it if itâs confirmed by a certain amount/percentage of others. Those rewards could come from subscriptions or donations, or simply from the networkâs SafeCoin rewards due to popularity of the app.
Another solution to tackle message spam on a higher level, is simply an app that introduces contact lists. Any message sent by someone not on your contact list would be blocked by this app and not shown to the user, or perhaps simply put in a different folder/category.
As part of messaging there will be black/whitelists held for you by the managers. These lists are under your control. So this will all be in the API for clients to implement whatever they wish including further analysis of spam / viruses etc. In this way at least there is a datum to work from and should allow clients to not be bothered with unwanted mail (from black or white-list settings).
We had some debate around this as to what the network should do and what it should not. We went for more a specific or specialised interface for messaging in this case. For a real generic message passing we will be meeting with one of the professors who designed corba for their input into the issues they seen. Thats for future work though, but for sure a direction of the network (generic messages including functions and zk-snark proofs etc).
Some great points there! I understand that these may be at a higher (client) level, but they would be a great compliment to the solution.
I suppose there are two issues here - filtering at send time and filtering at receive time. If the former is addressed well, we save resources and reduce the need for the latter. However, both issues can be addressed to improve the overall experience (but in different areas of the system).
If we can have some sort of like/dislike sender (in a spam sense), then bad actors would get suppressed and good actors would get promoted. If this was an optional receiver side filter, it could be rather powerful, much like eBay ratings, etc.
Eh why not just use autonomous agents? Also why not let the sender attach a payment to each message paying the receiver for the receivers attention?
The senders will then have to bid up to get the attention of the receiver. Autonomous agents could handle this entire process.
How much does it cost for me to get your attention? How much does it cost for you to get my attention? You want priority? Pay for it and go to the front of the line.
Design features such as an occupied sign could be useful but itâs not enough. Itâs also important to change the incentive structure so that low priority messages wonât bid to the top and high priority messages will rise up. If low priority messages from complete strangers require a payment then that solves everything. You would receive payment from strangers who request your immediate attention.
Why not just go with the paid messaging model? How can there be spam if the spammers must buy our attention?
They can send the messages but messages will have to attach Safecoin in order to be received at all. This way every single message has a cost. The safecoin goes to the receiver who must spend their attention reading the message as compensation and suddenly spam becomes unprofitable.
I request that this feature be put into any messaging system built on SAFE Network. It is a critical feature because it aligns the incentives in a way which empowers users and reflects on the fact that attention is a finite resource.
This is part of the problem. I think sending messages should cost Safecoin because all the resources are finite.
Storage resources are finite, attention is also finite. In fact attention is the most finite resource of all and the solution is to close the loop. Human attention either is finite and therefore has a price or we can pretend like itâs infinite and be flooded with ads, spam, and unwanted information which we donât have enough attention to process.
The bigger problem is attention scarcity. For more on that read my thread which so far has received very little attention but which is discussing the central problem behind all of this:
Iâm against this for white-listed contacts. Yes my attention is finite, but the act of white-listing someone is a declaration that Iâm willing to offer my attention to that contact, without monetary costs. If a contact crosses the boundaries of grabbing my attention unreasonably often I have the choice to black-list that contact.
I really donât want to have the most basic aspect of digital social life (chatting) to involve money, no matter how little. Besides, have you seen teen-agers chatting online these days? The sheer amount of instant messaging they do is insane. Even a tiny messaging cost will sum up to a considerable amount per month for them.
Something like this would be fine, as long as you can cancel the invitation/message yourself as well. There are always reasons why some people who you know from real life donât accept you (inactive accounts for example). Wouldnât want that escrow to be stuck forever due to such situations.
Oh, and this mechanism could also be implemented at a higher level than core.
In my view the bottom-line should be that anti-spam measures shouldnât interfere with non-spammy communications, or else weâre going to lose this battle against other instant messaging services. The general populace values convenience above all else, including privacy. We shouldnât provide privacy only to those who realize how important privacy is, but also to those who do not. That means we should try to provide an all-round better user-experience than competitors, and not sacrifice convenience. If people donât use MaidSafe due to inconviences, weâre not providing privacy for them at an acceptable cost, and the âSecure Access for Everyoneâ ideal fails.
You have a right to this and I support having it in the SAFE Network platform. But I also want the right to quantify my limited attention and commodify it.
If advertisers and people not on my whitelist want my attention they should pay for it. If complete strangers want my attention and I havenât specifically added them to my whitelist then they should pay for it.
In my opinion attention is something big companies make money off of but with a sense of entitlement where they feel they own our eyeballs and can sell them to others. It is important to take back our eyeballs in my opinion.
You might not want the most basic aspect of digital life to involve money but every aspect of life involves money. So if the people chatting arenât making money off their content then someone else will instead. If chatters donât make money from their data then the data will simply be stolen, hacked, and sold.
All data has some price and is a commodity. All activity has a cost in terms of calories if youâre human. This means all chatters must eat and all of their activities are accounted for or they die of starvation. In my opinion the system should be in place to allow atomic granular microtransactions so that any activity participants decide to monetize can be monetized in their favor.
As long as white-listing makes normal plain-text chat free, I have no problem with your ideas at all. From the way you phrase it there seems like thereâs not really a conflict.
we always do though.
-)
