There are two areas of the API which I think are missing and need clarifying before standard Web2 features can be considered seriously by developers. Until that happens I don’t think it makes sense to begin work on applications requiring some very common Web2 type capability. This is even before getting into new areas like versioning of data and concurrent editing (using the RegisterCRDT API).
These areas are the capabilities and APIs for mutable data (i.e. Registers) and for messaging (which has been discussed as a way to send payments to data).
Here’s a standard Web2 interaction and thoughts about the ways it might be supported in a Safe API using on of these approaches.
Blog Comments Implementation
Blog comments are effectively an unsolicited communication from any person to one public identity, and one of the main problems with them is spam.
As the Safe Register API stands, any implementation will be vulnerable to DDoS type spam because there is no cost to writing to a Register, and the only way I see for either a) anyone to write a comment, or b) to offer a way for anyone to sign-up to comment on a blog, requires a Register to be publicised that anyone can write to. But there is no cost associated with writing to a Register, so anyone can DDoS it by filling it up with garbage.
This must be solved because a fundamental of Safe Network is to avoid censorship.
A way to combat that might be for the owner of a Register to set a fee for anyone else (or any non-authorised identities) to write to the Register (or perhaps for the network to set such a fee, IDK).
There may be other ways to implement this, such as the messaging that has also been alluded to that may provide a mechanism for anyone to send a payment to any data or identity on the network.
So there are no doubt solutions to this problem, but what is not known is either the underlying implementation or the API that may or may not be available by a particular date.
This makes it hard for a developer to consider or begin designing an app which requires unsolicited communication from unknown third parties (e.g. anything requiring capabilities such as posting a comment, applying to sign up etc).
I feel this direction may be the most desireable route. Forcing users to pay to post messages, and allowing an easily searchable way to surface those messages (if unencrypted); via the DAG. It neatly solves spam, and ties things to an address. We’d need to flesh this out in more detail to be able to timeframe this.
Hopefully we’ll be working towards that soon. I appreciate the uncertainty is a blocker right now.
You’re right, I thought only about a spamming motivation for such attack.
I have an alternative approach – if everybody just had own register for comments, and the register’s address would be for example hash(post_addr xor username) you just had to know whose comments to read, perhaps users could share lists of other users worth following in this topic… it would be some kind of trust network.
edit: but it could lead to register address squatting… :-/
Yes, agreed and atm I think that’s the only workable approach but it is limited. Maybe that’s ok, IDK.
In effect you have to be invited by someone which is not a bad approach. By invited I mean there’s no way for me to approach you, you somehow have to notice me and pick up a feed that I have made public. So someone you follow may mention me in their feed, or perhaps. But you still can’t communicate with me until I find you!
Another issue is that people are lazy so I can imagine people finding some neat feed and following that, telling others about it and some feeds becoming very popular. A form of centralisation - not sticky, except that people are lazy so there’s an inherent stickiness one people being following.
So I think its a bit limited, but could be nice.
I used Blog Comments just as an illustration, but it illustrates a limitation, because it doesn’t work: to comment the blog owner has to find you and start searching your feed for comments on the blog.
That could be solved by commenting user generating a secret, creating a register, and this secret would be published, when someone adds him to his “trustlist”. That secret would be xor-ed with post_addr instead of username.
I think using words as a salt is quite a nice option for an NRS based on registers. Every string you can think of operates like a TLD (top level domain) and the domain part is combined with the TLD part and hashed to generate the register address.
So I choose “code” as the TLD ‘salt’ and reserve a few code+domains based on it. Anyone can register their own code+domain long as nobody else got the domain part first. Yes people will squat but if we have a public decentralised system I don’t think we can avoid it. The nice thing is that there will always be new TLDs because any string will do, and nobody owns the TLD, they can only claim domains associate with it.
The alternative is to have users own something - which is maybe why @joshuef is think of using a public key - but I don’t see how they can be human friendly. Let’s see what those bright sparks have in mind!
I don’t understand your “address squatting” post, can you elaborate?
perhaps it could be done on side-channel, like I see your e-mail on your profile, and just drop a message “hey, I see you participate in this Safenet forum on making pickles, perhaps you could invite me? I make very good pickles and have some interesting insight on pickle spices I want to share”.
I’m not sure I get it… Isn’t it like everything in life? If there is one forum about pickles, perhaps most people would be there. But perhaps there would be another forum without politics, etc. I think it’s the point of communication – the more people participate, the more views are being shared. I would not call it centralization…
Sure… Or perhaps comment addresses could be created as hash(post_addr xor 1), hash(post_addr xor 2), etc. There could be spam, but each post would cost money, so perhaps this is a solution?
It’s similar to what you said about salt-based NRS. For example, there is a forum post about Safenet, and I know you are interested in the topic, so I could squat address hash(post_addr xor "happybeing"). But I think this could be solved, for example like here: Clarifying Safe APIs - The Blog Comment Problem - #7 by loziniak
To clarify in my other post, the PK is arbitrary and un-owned for an un-controlled namespace. But the fact it’s a PK is an artifact of register addressing at the moment. (See other thread for more deets).
