Token creation via GUI

[dexX7]

How much work would it take to support token creation from the GUI?

Just thinking: the meta DEx is probably more fun, if there is a way to create tokens, too.

I'm primarily asking, because, if I recall correctly, then this was almost ready, but the integration was postponed. Is this correct? If not, let's integrate it later.

[zathras-crypto]

How much work would it take to support token creation from the GUI?

A day or two - definitely manageable :)

Just thinking: the meta DEx is probably more fun, if there is a way to create tokens, too.

That may indeed increase user participation... However... I was going to raise this regarding the RPC calls but just hadn't had a chance yet... One of the reasons I don't think we have a huge number of spam properties is because it's not easy to create properties - usually we provide assistance to projects wishing to create tokens (usually in the form of python scripts)... Since I've added the ability to create properties easily via RPC calls (and it would become further even easier if we added the capability to the UI) it's probably a good time to revisit the question of anti-spam fees for property creation... I'm all for making it easy - but with that comes the risk obviously of spam - I would argue that smaller property ID's are more valuable - eg an issuer would prefer "property 3" than "property 756432" and thus we should discourage spam where we can. It's possible to create properties (albeit with short names and minimal values for fields) with class C for fractions of a cent meaning to spam say 100,000 property creations is not an expensive proposition.

TL:DR; I would like to open the discussion on a 1 MSC fee (to be burned) with each property creation. I think this fee is negligible for all intents and purposes but serves a strong anti-spam purpose (in that spamming 100,000 properties would then require one fifth of all MSC tokens in existence).

Paging @dexX7 @CraigSellars @marv-engine @msgilligan @achamely @OmniLayer/core-development @OmniLayer/owners

Note - I don't consider an end user that wants their own property as spam. I consider someone sending creation after creation after creation as spam.

then this was almost ready

I have some local scraps but nothing complete - but as above not a large amount of work - my question is more around whether we should make it easy - if the answer is yes then no worries I can take care of adding the capability to the UI :)

[dexX7]

As long as we don't run out of property identifiers, it's not an issue in my opinion, and while low numbers might be nice, it's probably less interesting, once 4 or 5 digits are reached.

In the long run, I'd like to get away from ascending, global state-dependent identifiers altogether, and consider something like Identify property by issuance transaction #280 as alternative.

Since property registration isn't authenticated to begin with, no fee can stop name squatting either.

Spam, in general, is sort of an UI/presentation related topic, whether in the context of property/transaction explorers, or the wallet ("I received unwanted tokens with shady advertisement urls in the description").

Introducing a fee to accelerate the burning of MSC is yet another story though.

[zathras-crypto]

In the long run, I'd like to get away from ascending, global state-dependent identifiers altogether, and consider something like Identify property by issuance transaction bitcoin#280 as alternative.

We can certainly re-open that discussion, but I just can't seem to get my head around the idea of using such a large space (uint256) to communicate a unique ID to users (and since the property ID is the only thing that can be trusted that is what has to be used).

Telling users to interact with "token 456" is infinitely more 'user friendly' than telling users to interact with "token 3bb177e71df2f3ab58dd16358758f6daf03a4263e78cd0af29458544722b5cc8"

[dexX7]

the property ID is the only thing that can be trusted that is what has to be used

Yeah, very true.

Telling users to interact with "token 456" is infinitely more 'user friendly' than telling users to interact with ...

Interesting point of view. Ideally, the user should not bother with identifiers at all, because they are a low level detail, like "ECDSA signatures" are the low level detail in the context of "sending some coins".

I'm not sure, how it could become more user friendly, but discouraging property creation to artificially limit the number of properties probably won't work for long.

[zathras-crypto]

Interesting point of view. Ideally, the user should not bother with identifiers at all, because they are a low level detail, like "ECDSA signatures" are the low level detail in the context of "sending some coins".

Without an identifier though what separates one token from another? Even "BTC" vs "LTC" are identifiers no? :)

but discouraging property creation to artificially limit the number of properties probably won't work for long.

Just to be clear on this bud, I don't suggest to artificially limit the number of genuine properties created - I suggest to limit the number of identifiers wasted to spam. TL:DR; I would like:

• anyone who wants a property to be easily able to create one
• anyone who wants to harm the system by generating useless property ID's to face difficulty

Let's take an example - I want to use property lookup to search for MaidSafeCoin, but someone has spammed (let's choose a fairly low number) 500 properties also called MaidSafeCoin. That's essentially a denial-of-service to the property lookup function and renders it pretty much useless. With a spam fee of 1 MSC that would cost the attacker 500 MSC. Without the spam fee that would cost an attacker perhaps 2 bucks. We'll always face cloned names and such (unless we enforce unique names, which is another possibility) but as long as we continue with the methodology that properties are identified by name and ID I see quite a risk. Going back to the lookup function - picking "MaidSafeCoin (#3)" out of a list of 5 or 10 objects is not too difficult - picking it out of a list of 500 or 1000 objects it is much more obstructive.

TL:DR; I don't see a 1 MSC spam fee as solving all the problems, more of a harm reduction technique. There will still be spam, just not to the level of denying service to functionality.

[zathras-crypto]

Oh, also while on the topic - I still stand by my old-skool suggestion of adding a field for 'symbol' to property creation, and allowing requests for a 4 digit alpha numeric symbol which would be unique and could be termed as the identifier. If you request one that's already in use your creation is invalidated.

This way Tether for example could be "identified" as USDT and MaidSafeCoin could be "identified" as MAID and so on. I see this personally as a great target for end user usability. This can simply be a user facing attribute with very minimal back-end coding work required.

Also to note, any changes (from spam to identifiers) is a new transaction version for the property creation tx's - @dexX7 you're no doubt aware of that just wanted to note that for any others joining the discussion :)

[dexX7]

but as long as we continue with the methodology that properties are identified by name and ID I see quite a risk

There is also the issuer to name in this context.

4 digit alpha numeric symbol ... If you request one that's already in use your creation is invalidated.

I'm not sure, if I follow correctly. If the identifier is no longer a number between 3 and 2^63-1, but a number between 3 and 9999, then it's actually even worse?

To make my standpoint clear: I understand the concern in general, and I fully agree that it's an issue, but I'm not 100 % convinced by the "fee as solution", primarily, and to tackle it from another perspective, because it doesn't scale and simply delays the underlying issues, while it likely has a negative effect on user adoption.

[zathras-crypto]

I'm not sure, if I follow correctly. If the identifier is no longer a number between 3 and 2^63-1, but a number between 3 and 9999, then it's actually even worse?

No, sorry - let me clarify - no changes are made at all to the existing property ID system. There is an addition of a field to the message, for an optional 'symbol'. This 'symbol' must be unique (ie not used by any property prior) and must consist of an alpha-numeric 4 digit pattern. This then allows issuers to communicate to their users (and interfaces to interact with) a very simple method of identifying the property without worrying about copies or lengthy numeric property ID's - for example:

MAID = MaidSafeCoin (#3)
USDT = TetherUS (#31)

EDIT: to clarify, if I then go and create a copy "MaidSafeCoin (#43)" I can't reuse the MAID symbol - thus for end users all that needs to be communicated is to interact with the MAID token for the user to safely identify the correct token.

Long story short - no changes at all to existing rules, simply the addition of a unique alphanumeric code (of which there are about 1.7 million possible with 4 chars) if the issuer so chooses to aid in usability of the token.

To make my standpoint clear: I understand the concern in general, and I fully agree that it's an issue, but I'm not 100 % convinced by the "fee as solution", primarily, and to tackle it from another perspective, because it doesn't scale and simply delays the underlying issues, while it likely has a direct negative effect on user adoption.

Sure sure, I don't know that a fee is necessarily the right solution - hence the discussion :) though personally I disagree with a negative impact on adoption - I personally think those subset of users who want to create their own token needing to pay a (very small) fee is less harmful than forcing all users to trawl through lists of hundreds or thousands of spam properties trying to find what they want.

I'm absolutely not set on a fee - but I would like to find some method of protecting our ecosystem from someone kicking off a script to issue thousands of properties for just a couple of bucks once the RPC calls become available in 0.0.10.

[achamely]

I'm all in favor and have been on the addition of the symbol field and the msc fee to create a property.

Though we'd need somewway to account for the properties already created and making sure it doesn't cause conflict

[zathras-crypto]

Thanks for the input :)

Though we'd need somewway to account for the properties already created

Yeah part of adding a symbol would be allowing an issuer to add one to a property they have already created (only if they don't have one already - ie no changes if you've already picked one, just addition if your prop was created without one).

[dexX7]

I like the idea, this would be a lot more user friendly, but the concern stands, unless I still misunderstand the idea.

Even if it doesn't change the way how properties are identified, if there is an (optional) 4 characters identifier, then I would imagine properties would be created, just to reserve the short-identifier.

Imho such an approach is only really useful, if the identifiers are allocated manually, e.g. in form of "premium services" as you once proposed, where issuers are authenticated (e.g. "tUSD" could only be reserved by Tether), but otherwise the identifier/name squatting risk is still given.

[zathras-crypto]

I would imagine properties would be created, just to reserve the short-identifier.

Yeah it would most certainly need to be coupled with some form of anti-spam (which I still feel is necessary - I've been asked the question probably more than a few times "what's to stop someone creating a large number of properties" and when I respond with "nothing at the moment" it's always an "oh" moment hehe...)

Imho such an approach is only really useful, if the identifiers are allocated manually, e.g. in form of "premium services" as you once proposed, where issuers are authenticated (e.g. "tUSD" could only be reserved by Tether), but otherwise the identifier/name squatting risk is still given.

Yeah that's a fair point actually (re symbol squatting) though to be honest I didn't get much response for the notion of 'premium services' - I actually tried to sell the idea by trialling it on OmniChest (forfeiting foundation hosting cost-coverage in lieu of property registration and sponsored properties (http://omnichest.info/sponsor.aspx) but in the six months since I did that I've had zero takers so rather than raising revenue for me it's actually cost me about a $K so far - typical heh! though recently I did reduce the infra down to 3 servers of lower grade to lower costs :)