Hey y’all. I’m posting some updated terminology for the ICON Network (see bottom of post). The purpose of updating terminology is to grow the ICON community. Using terminology that is familiar for the general community of cryptocurrency developers, power-users, and enthusiasts is one of the easiest and best ways to encourage participation and cross-pollination of ideas.
The list that I’m posting is a draft. Meaning that it is not final. Additionally, we are welcoming comments from all parties so that we can mix-in different people’s opinions and create a terminology set that is agreeable to our current community. The plan for deprecating old terms will take a while, possibly 1-2 years, so you will definitely still see the old terms referenced in future publications and discussions. However, official content outputs by ICON Foundation will be trending towards using the updated terminology.
I’m aiming to post this list onto the Developer Documentations on Monday, March 28. After that date, we will always be open to further updates to terminology as seen fit by the ICON Foundation and the ICON Community.
The Google Doc posted at the bottom contains the terminology list. Please discuss in this Forum post if you have any thoughts. The Google Doc is open for comments as well, although I’d prefer to discuss through this forum.
Edit 1: After an internal discussion with foundation members, we are proposing to remove the term “Delegated Proof of Contribution”. as well. This is in favor of correctly referring to the consensus mechanism as “Delegated Proof of Stake” and clarifying the definitions for “Contribution Proposal” and “Delegate / Validator” to include information about Delegates / Validators incentivizing the ICON Community
Edit 2: I’ll be posting this on ICON Community Glossary tomorrow. We just updated that entire site, and I’ll need to coordinate with some folks to get everything updated correctly
I think the updated terminology in the document is great. Reduced acronyms and clarification around the language of ICON Bridge relative to the key steps for BTP are a good move.
I do however prefer ICONists over ‘Community Members’
I find it gives more a sense of belonging and community, beyond just being a service user.
@ICONJohn I’ve heard similar sentiments about that term as well. My take is that this term and similar should be pioneered by the community rather than by the foundation itself. That way it can be clear that ICONists exist, and the foundation can acknowledge these folks as key members in the community, but the avenue for people to name themselves differently or participate without a group name is more clear
Sink blockchain might be confusing, I’d go for: Target (block)chain
I’m not really a fan of ICON ‘Bridge’ it makes it seem like BTP is too far away and its a mock up of any random bridge, BTP is known to be a game changer and an innovative product, the word ‘bridge’ just dampens it down. I’d prefer a narrative around it being refered to as: BTP Beta.
because it is just BTP without the BMV
Light node, possibly change to: light client?
other than that, really like the changes and the thought of direction on many, especially changing p-rep name
For “Sink blockchain” – I have added the terms “Target blockchain” and “Destination blockchain”, and suggest that we support all three interchangeably. I agree that “Target blockchain” is a good term. “Source” and “Sink” are common engineering terms, so it may be useful to data analysts or engineering theorists. Likewise, “Source” and “Destination” are common function call parameters for modern programming operations. For example: the cp (copy) function includes the src and dst parameters
For “ICON Bridge” – This term is used instead of “BTP 1.0” for two reasons. First, the “Bridge” product is a centralized product. When we release it, we want the community to be clear that we are intending to release “BTP” as a decentralized product as has been communicated previously. Secondly, because the switch from centralized to decentralized has many important repercussions, I think that likewise a version update from “1.0” to “2.0” will not underscore the importance of the new product as much as the foundation would like.
For “Light node” – I have added the term “Light client” to be used interchangeably with “Light node”. I have seen both terms used interchangeably to refer to a blockchain node that supports a partial rule-set of the network. See this article, for example. For this reason, I think that we should support both terms.
However, I am still stubborn on the ‘Beta’ name. I don’t really see a name differentiation between the centralized roll-out phases in comparison to the total roll-out phase, just as we are seeing with L2’s right now.
I am also interested whether standardization for the terminology of btp wrapped assets has been created. I think it’s very important to gauge community opinion on the standardization of tokens that may travel across many chains
Hi @errcsool, thanks for your work! I’m curious if there’s a changelog available or if the terms that have been updated could be highlighted somewhere.
@soso This is the first official output of a terminology list from ICON Foundation. As such, there is no changelog. However, all old terminology is still included in the terminology list as a part of the transition plan. I outlined it a bit in the post. Basically the terms with square brackets next to them are updated and the text inside of the brackets describes the nature of the change
Edit: The old terms will be on the official documentation output as well, with a similar note about the nature of the change and if it is being deprecated or not
@Digitaldave.eth I like the term ICONist as well! To this point, I propose that the community takes ownership of the term. I think it’s a little bit of an improvement in terms of growing the community and, frankly it’s a bit more fun in my opinion of the community has names for itself rather than those names coming from the foundation.
@Ali A lot of great points there. I will bring up the point of “Bridge” vs “BTP Beta” again, but the consensus within the foundation and the associated product working group is to use the term “Bridge” to differentiate decentralized vs centralized.
As for the point about BTP wrapped assets, stay tuned on that one. I will be sure to have someone share all appropriate BTP-related standards with the community for viewing, commentary, collaboration, etc
Just to reiterate, what I mean about ‘beta’ is not specifically calling it ‘BTP-Beta’ but the notion/narrative around “we are launching BTP in its Beta phase”, i.e. step phase one is to launch BTP without the bmv.
Do you think it’s worth differentiating “API Endpoint” and “API Node”?
I wouldn’t call myself a developer so I could be wrong on this. When I hear “endpoint”, I think an IP address or domain name that can be used to access some kind of infrastructure. In the context of ICON, an “API Endpoint” could be “ctz.solidwallet.io”. At the same time, the “ctz.solidwallet.io” in itself is not an “API Node” because it’s more of a proxy that handles the request and routes it to a node that is closest to the visitor. Similarly, an “API Endpoint” could be offered by a paid service like Infura and have built-in permissions with JWT or whatever – access to the node is done through the endpoint.
So, I think “API Node” is the actual server that responds to a request, while an “API Endpoint” is a hostname that can be accessed via HTTP or WSS to pass a request to the “API Node”.
