Fresh safecoins from farmers

…hey! I warned you, it was gonna be controversial :smile: , seriously I agree with the concerns and totally share them.

I agree the network shouldn’t be aware of things like Public Names, but if we think about it that idea can still survive, we actually can have a non-transferable data type and that’s all the network knows, so let’s say we have a Non-Transferable AppendOnlyData, which can be used for several things by users/apps, including having Public Names to be defined as NonTransferable AppendOnlyData, and no need of something like the crazy fresh-safecoins, so users can create them but they are owned by the pk which were created with, using safecoins. I agree with @happybeing that renting might still happen, but it will be impossible to know really what would happen, I tend to hope that users trying to run serious business would realise that renting is not really an option. Another example, renting a public name for publishing a wallet app has such a big risk of having my app’s users scammed and my whole app to disappear since after such an event I cannot simply move it to another public name, nobody will trust my app again…I’d hope! :slight_smile:

I agree that removing fungibilllity is a big issue, no doubt and I wouldn’t try to deny this idea has that effect ofc. So let’s now introduce the possibility of transferring from FreshCoinBalance to FreshCoinBalance, I know…this is effectively having a second coin and market, where the network supports the exchange of one for the other but in a single direction (fresh → non-fresh). In this scenario users would still be able to transfer coins to others for them to create their account.

As a final comment, all I’m trying to do here is expose some thoughts and ideas, even if they are crazy and/or stupid, that’s the reason I joined the forum in the first place, that’s all.

13 Likes

That’s an interesting idea I’ll give some thought. I’m still not in favor of a duel coin economy (for the SAFE Network) but I think dual coin economies have their place. It is a whole other thing to educate people on and in this case raises the barrier to entry for certain services that really should just be easy and accessible to all. Not that I haven’t personally worried that someone might squat a name I might want so I’m happy folks are thinking about it. :slightly_smiling_face:

4 Likes

We can have a data type that is tied to one account and non transferable between accounts - not non transferable - if we’re honest here

so I personally would try create one account per data of that kind because there is really nothing of which I would be sure that I don’t want to give it to anybody else at some point Oo…

freshcoin are farmed - and freshcoin can be spent for storage - and freshcoin can be transferred to others as freshcoin

freshcoin is safecoin with an additional bit marking it as freshcoin


As everyone I appreciate your unconventional thinking and additional input =) but imho the naming system should be an exchangeable plugin and the network should not have to worry about it for now - there is more than enough moving parts in this puzzle and enough tasks for maidsafe the company - and if it turns out that establishing a network level solution is the only reasonable way to do it when we’re in beta (and the other parts have been proven to work) then we still can turn away from plugins and implement something in the core of safe

2 Likes

you are absolutely right, I forgot to mention there that in this case we’d need to restrict the fresh ones to be only for those operations like acc creation, but you’d need the non-fresh for the rest, good catch.

How would I downgrade to ‘non fresh coins’ then?

(and that would lead to two different usable coins where people would manage how many of which are in existence… So the autonomous network wouldn’t be autonomous anymore)

But that would mean that one would have to “buy” coins to upload data, that may be problematic if you live in a place with a very strict ruleset or people who simply don’t want to (like me, if possible).

edit: Oh, make two wallets and exchange between right?

yes, you’d transfer them to a non fresh-CoinBalance

1 Like

Great food for thought post @bochaco, thanks for sharing crazy ideas. I am not a fan of FreshSafeCoin or rebranded token for the fungibility and complexity issues it introduces as many have mentioned. However there may be value in a private simple accounting entry/signed proof: “This account ID has farmed X Safecoin” (or even a whole list of entries over time). The user may want to expose some or all of this information about their account as proof of work for any core or third party App services that require raising the bar for entry.

P.S. The public name system RFC discussion deserves it’s own thread for community comment - perhaps with a summary of what the dev forum crew have decide so far on behalf of the community (yeah, I don’t like the idea of a separate from the communty dev forum).

I’m not opposed to the idea of fresh-coins. I am opposed to limiting them to specific functions.

I like the idea of rewarding and giving incentive for people to farm and help it grow. However, what you are proposing sounds like punishing and excluding non farmers. IMO the only way to do this would be to give, say, a 10% discount on network services to fresh-coins. They would also need to be non-transferable.

I think the current design here promotes easier phishing attacks too for what average clearnet web users are accustomed too.

If user A buys: safe://payment.com
And malicious user B buys: safe://secure.payment.com

Average people will think of the two safe websites as the same owner/trust in my opinion. I think the network should reject the purchase of names that in clear net would be considered a subdomain of an existing name to prevent exactly just that. I think keeping the learning curve down where it can be low is better, and to mirror common practices clear net has without sacrificing the principles of SAFE. Arguably to do so though also goes against my keep it simple mantra to get us to MVP because right now its simple as ever where its just a 1 to 1 map, buy this exact name and thats what you get.

That is not possible. Names are flat and there is no buying “sub-domains” which cannot be done on clearweb either.

Without a registrar there is no way really to prevent human similar names from appearing. Every time you make an algorithm or method to stop it they find another way to get around it. And the less simple a scheme becomes typically there are more ways to abuse it.

1 Like

I like this idea of having a browser plugin manage domains … so maidsafe might only need to reserve .web, .web2 … etc tld’s … then a particular plugin with a particular system of domain management would be able to handle the rest e.g.: safe://google.com.web … where each plugin would handle only a single tld.

In this manner we can have any number of domain systems catering to whatever people like.

One plugin might have a 30 year contract with option to renew … another might be pay as you go, another might be in perpetuity … another might auction it off to highest bidder at the end of a period of time … whatever you want, you can have it as a system … just build yourself a plugin and buy a tld from maidsafe.

Lot to think about here…but to clarify (at least in my head) sounds like the all purpose of this dual coin idea is preventing:
1- PN squatting/spamming
2- uncontrolled SAFE Accounts creation
@bochaco please correct me if I’m wrong

For point two, frankly that doesn’t worry me, unless it affects network performance or ability to expand. Not dissimilar problem to having your name taken in gmail. Not a biggie

For point one, on the other end, the implications are much more worriesome. In particular using clearnet big corporations domains for fraudulent or propagandistic reasons, which as mentioned could kill the safenetwork reputation. But also the overall effect of spamming and squatting

So my .02 :

I don’t believe there’s a silver bullet, but a combination of things

a- As @Dimitar mentioned, witholding certains PNs, with criterias to be defined, by Maidsafe foundation as @neo suggested. Release method to be discussed as well (paid or not?)

b- using a community rating system for PNs. And here is when I think it becomes very interesting. I’m imagining an icon next to the safe: address reflecting the community reputation for that PN (yes, foundamentally the green lock on clearnet…but community based). The trick here will be making the reputation based on the right parameters…and maybe @Seneca 's effort could help on this…

Back to (strict) topic, don’t really like the idea of the dual coin. More because I question whether it is the right answer to the problem.
An app-level solution as hinted above, plus some level of control (as minimal as possible) from maidsafe foundation, are less abstract/more practical ways to deal with the problem IMHO.
As for the proposed new data types, if they can help with the above, sure…

1 Like

That is an interesting idea. The Name is an AD so there is the option to have the rating stored with the name record.

Maybe vote on

  • valid
  • illegal
  • scammer
  • etc

But this too can be abused by down voting a good site to attack a competitor

2 Likes

If this could be managed by a plugin and hence not in the core Safe Network. Then there are multiple ways of doing things and choice is preserved. Also easier to adapt to the manipulators.

3 Likes

If at network level, I suppose it comes down to who has the right to write/append that information. Elders through parsec?

If at app level, you would hope non genuine ratings would avarage out, unless the whole rating-system-based economy is flawed…eheh can of worms

Like it.

Freedom to create any domains, on any plugin, with that plugging referenced by the last .web.:grinning:

With an option to go to a trusted organisation like MAID to register a domain on a rubber-stamped plugin.

One of many good business opertunities for maid foundation.

I see ICANN also muscling in on this, since they already are some sort of domain provider.

This would legitimise the SAFEnetwork from a “think of the children” argument.

Of course … The “Dark SAFENet” will exist by domains not on a rubber-stamped plugin, in the same way the current “DARK internet” exists already.

We can then shuffle all criticisms of the SAFEnetwork towards the existing problem of the darknet and there is nothing we can do about it.

1 Like

Really I see that as irrelevant since people’s votes have to be recorded somehow, and once that happens its possible to bias that

That’s a great point, hadn’t even thought of that. But yeah could be a good way to manage/separate out darkweb stuff from mainstream and many would prefer that for sure.

.web .grayweb .darkweb !! install whatever browser plugin you prefer … or install them all.

Though I wouldn’t explicitly state .darkweb
In the same way today there is no explicit statement of a darkweb. It’s just possible to do.

On SAFENet darkweb will be possible by not taking part in rubber-stamped plugins.

1 Like