Abstract Coin/Coins and Accounts to be more general

[rigelrozanski]

It would be nice to abstract out the types:

• Coin/Coins
• Accounts

These two types could be re-implemented for specialized basecoin-plugins. For instance, maybe you want to turn the "coin" object into a smart-invoice that can get passed around with context for an expanded Account type.

Thoughts? Is there anything else that should be abstracted out while were on this train?

[faddat]

That's very interesting!

UIAs would be made much easier by abstracting out those two types.

I found the basecoin plugin structure fairly rigid. I could be wrong about this but is it basically designed such that there's no entrypoint for code that isn't satisfying the interface?

That's not really a negative mind you-- just trying to ensure I'm using all of this correctly.

[jaekwon]

What's a UIA? How is the Basecoin plugin structure rigid? You have complete control over the application state through a plugin so you could do just about anything with it.

Coins are needed per account in order to pay for tx fees... While I think we could abstract it out, there would have to be a good reason for it. There are benefits to standardization, such as the ability to use common logic for various applications. Or, out-of-the-box compatibility with the Cosmos Hub. Public blockchains need some kind of spam-prevention system.

Abstraction isn't always desirable, nor is sticking to bad design. If we want something besides the Coins system, we need to assess the new design as it relates to the whole ecosystem. What's a concrete design that can replace the Coins system?

[rigelrozanski]

@jaekwon hmm... you know what, I'm now thinking that coins are really just a subset of a higher level object which can be exchanged between accounts - if we built out the architecture for exchange of a more generic object type, then we would never need to abstract out coins but could build custom objects that work along side with coins, This way we keep the standardization as you pointed out, while allowing for expandability. I will have to ponder on what some of fundamentals of this generic object... Nonetheless I think this idea make a whole bunch more sense than abstracting coins... Thoughts?

Also maybe accounts don't need to be abstracted either, maybe through using a []byte object we will be able to add in custom information for use within a plugin... I'd like to somehow be able to use the native accounts with customized information for plugins. good ideas here thanks for the feedback

[faddat]

@jaekwon

Absolutley. Compatiblity with the cosmos hub is why github.com/dawn-network/firstrays is how it is. Our goal is to build in the most standard way possible.

Also-- about rate limiting, I agree there as well, and it is a tough nut to crack. Steem did rate limiting through a currency, of sorts that was called bandwidth and was awarded on the basis of non-spam transactions. So if someone was spamming, they would run out of bandwidth.

Also, I had a look at web3.js. Tendermint (ethermint) chains are much better suited to its goals, IMO, because they are lighter, faster, and can be further optomized. It's interesting that web3.js exists-- when I called my writeup w3, I did not know that it did. I stopped following eth news when it was decided that they'd roll back the chain for the DAO.

That was probably not the right move, but only hindsight is 20-20.

@rigelrozanski - could you sketch out that object?

[faddat]

Just a quick thought here:

Tendermint is (can be used as) a library already. Might it be better to actually:

• assume that there's always going to be plenty of PEX nodes avaialble
• in a basecoin library or tendermint library, allow the developer to set the chain ID, something like "glogchain".
• Put a list of default bootstrap nodes into tendermint

I think that this would make for a faster development process, because bootstrapping the network would be a zero-effort affair-- nodes could come up one by one and as long as the chain ID matched another node, they'd get paired. IMO, it would go a long way towards having TONS of TM chains that are all compatible with Cosmos.

[rigelrozanski]

@faddat I'll post a concept plan here for a more generic object that encompasses the coin once I figure out all the basic elements it should include - haven't spent much time thinking about it yet, but let me know if you think of anything useful for such an object that you'd like to see

[jaekwon]

@faddat How do we work on that together?

@rigelrozanski ... coins are really just a subset of a higher level object which can be exchanged between accounts - if we built out the architecture for exchange of a more generic object type, then we would never need to abstract out coins but could build custom objects that work along side with coins, This way we keep the standardization as you pointed out, while allowing for expandability. I will have to ponder on what some of fundamentals of this generic object... Nonetheless I think this idea make a whole bunch more sense than abstracting coins... Thoughts?

Sounds very cool. Are we creating algebraic types or what? Would love to see some examples.

[ethanfrey]

@rigelrozanski would love to see some more docs on this idea. Like 2 or 3 examples. I guess bonded tokens have a different logic than unbonded tokens. Is that what you mean here?

Will try to integrate all these changes in my deeper refactor, which I label 0.7. Please add your ideas.

[ethanfrey]

@rigelrozanski I find the idea intriguing but have no idea how to solve this issue.

Can you give some concrete examples that such a framework should solve and what it should look like?

[ethanfrey]

If there is nothing actionable here, I'm going to push this off from 0.7.

When there is a concrete proposal, please re-open it.