Because then people have to wait (how long???) for their mail address and cannot transact with another via mail till that is finished. Who is to administer the jerk who for one hundred safecoin takes all the new names just for kicks.
The time to wait for another to bid would have to be significant for it to be any use for that which its purposed for. A week, or do you think you need a month to allow enough exposure for all interested parties to see the new auction come up.
Should be possible as service on app level if name resolution is a plugin (probably not the network benefits in this case but still possible - and the applicant can use the name until end of the auction period)
I was more thinking about a week and maybe only for shorter words. I was hoping this could be automatic without administrating (or a minimum). At leas you know, if you checked weekly, what domain names are to be sold.
I’m with the others here that Maidsafe should preregister the big domains. If some idiot claims a big company name and puts crap on it because he doesn’t like the company, then you have a false start at day one with the network. Also the companies we don’t like should have a fair chance to get their domain here and use it. Otherwise adoption by the mass will be hard.
Yes really, really important and should have special attention. An idea I had was to reuse the bitcoin address format so you could perform small airdrops to existing bitcoin holders, just enough to play around a little with the network for a small upload or domain registration. See this topic:
Very interesting. Creates lots of possibilities, pros and cons as you say.
One thing I’m interested in is if names really can be non transferable? Making this hard or expensive is something that could be very useful, but I’m not sure it can be done.
For example, names are owned by accounts and I think accounts will have to be transferable, and your example does rely on this (at least so non farmers can obtain accounts created using fresh Safecoin). If I can transfer the owner account, surely I can transfer a name this way? So far I’ve not been able to imagine a way to avoid this.
A side point - I don’t think we can assume that people won’t rent names - many people do this now, even though it is often/usually a bad idea, same with email etc - but especially if we make it hard or expensive to create them.
Name rental may or may not be a bad thing, but I suspect it will happen regardless of fresh Safecoin (I mentioned this possibility just now in the name resolution discussion).
Anyway, it’s great to have such original thinking to chew over, particularly in this area.
I hope we don’t shoot it down too early! [Edit after reading the replies… ] Ahh.
Maybe someone could add a ‘name service’-plugin/app where you get e.g. safe://cn.yourwebsite.co.uk for the Xor address you give, when you can prove that you are the owner of the site yourwebsite.co.uk. This with a similar (one time) procedure to get an https certificate (like certbot from Let’s Encrypt) for your website.
I meant a separate naming system, done by a ‘central’ entity (app/service) on top of the Safe Network. So better to call it cn://yourwebsite.co.uk then (cn: clear net) instead of safe://cn…, where the system translates your cn://yourwebsite.co.uk to the corresponding Xor address. Or something like that.
Maybe that is also not possible. Certainly against the principles of being completely decentralized, but you can’t prevent people to come eventually up with solutions like that if the completely decentralized naming solutions are insufficient for some.
Edit: This cn:// naming system isn’t aware of domains of course. But you can’t omit it if you want to be able to port for example both www.yourwebsite.co.uk and www.yourwebsite.com.
To ensure perpetual accessibility to perpetually stored data I would argue for having more than one kind of sdns. Both centralized and distributed ones. Let the best one win.
Edit: Including all variants, paid, unpaid, etc.
…hey! I warned you, it was gonna be controversial , 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!
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.
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.
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
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.
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?
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).