Sorry to be a bother, I don't want my post to get buried though. Anyway someone can help me out with the Mac wallet installation from the tar.gz? Thanks guys!
I am liking the ideas behind the project. Might I ask - what specific DApps will be most successful or useful being run on throne nodes? I'm having a bit of trouble imagining use cases and this is probably due to me being a bit unclear on exactly how it will all work. I haven't gone through all of the posts in the forum in a while so I may very well be missing some stuff. Nice to be around these parts again though. Thanks LucD for awakening me from my long Bitcointalk slumber. lol.
Cheers!
in terms of what DApps would be most successful or useful -- I don't think any of us really know, but I would offer a few simple observations to help you thinking about the issue -- these examples are meant to be illustrative/informative of potential ways that the functionality we are trying to achieve could be implemented:
1. Just think of it as a client - server network that is cryptographically secured using the key pair and verification capabilities in the Crown Core. So, what can a secure open client server network be used for?
2. The first stage of applications are likely to just be a migration of services or applications which you have elsewhere onto the platform because it is less expensive, more secure, or ideally just better. For this first layer of applications, just imagine if you could spin up a docker container of any application that is easily containerized in a single container... don't know if docker will be used, but there will be some sort of containerization and orchestration capabilities which will be able to be used with the API. Imagine that initially all these simple apps are free to use, but that as the system evolves there would be different purchase models for different applications.
3. Each node operator will have discretion over and responsibilities for applications running on their node/tron. So there will need to be a service discovery and connection protocol, because users will be selecting a service and a node to run it on.
4. The application interface will just be a browser window. In the papers the "temporary mode" of Crown is referred to as the journal. Functionally, the best way to think of the "journal" implementation is probably just as a browser with a Crown Journal plug-in/extension -- or that is probably the quickest way to implement it. It's tempting to imagine a customized browser -- but that is probably overkill...
5. No computation is happening on the blockchain. The blockchain is just being used for transactions & keys -- that's what it for and what it is best at. The blockchain is permanent -- but the application uses are not.
6. So what we are talking about isn't DApps like Ethereum has popularized them. We are just proposing that one might be able to offer the existing applications that are out there, but in a more secure and efficient way. And we would like to invite developers to come to our platform as a marketplace for their applications over time -- since we would ideally offer access to a global user base, instant payment and our platform doesn't need to charge excessive fees to provide returns for venture investors...
7. In terms of what you would be able to do on this platform -- well, it's a general purpose platform for compute, communication and commerce. You have integrated payments and you can do whatever you would with any server, as long as it has been packaged as a service by one of the Trons/nodes. The services themselves may run on the actual machine which is also the machine running the Crown Server software we call a Tron, or it could just be another VM/machine/container which is controlled from the Tron or just contracting with the Tron. That will be up to the operator of the Tron -- as are the costs of services offered by that node/Tron. The nodes are thus each really running as cloud service providers, with access and payment managed through the Crown Network.
8. There are a number of logic flaws in the DApp model as it exists now -- and they are probably fundamental. The biggest issue with the DApp model is that by creating a true distributed application framework Ethereum has created an instrument for CENTRALIZATION -- not decentralization. This is because the point of centralization is in the control structures and logic in the DApps which can't be shut down. This logic flaw is precisely why Ethereum and clones of it are of interest to corporations -- because a DApp is a perfect instrument for someone to project control through programmatic means. In this way, I think we all need to consider whether DApps --as appealing as they may sound actually achieve the opposite of their intended object -- or whether there might at least be some unintended consequences. It would seem we should be open to logic flaws in this system since the existence of last years fork is a sort of testament to one of those logic flaws, and that was just an operational detail -- not the larger ones that scare me.
9. General purpose platform for compute, communication & commerce. That's a key to really think about. The value of a currency is from its many uses -- money is useful because it removes the coincidence of wants which constrains a barter economy. So the best way to create a valuable currency is to create something with many uses... a sort of leatherman tool.... But the other quality of money is that you have to have a community of users -- you can't just build something perfect do an ICO and expect everyone to come -- you have to build the code and the community together and we all have to have ownership. It has to be shared.
10. Anyone launching a coin with a single use, or focus, by definition may be a genius coder -- but they are economically stupid and don't understand what a currency is or why money exists. Anyone doing an ICO also faces an uphill battle because they also don't understand money, and the fact that it's value is socially constructed and that it also needs to be broadly distributed to those who find it useful to be of value -- money does not appear in a voila or unveiling -- or if it does it is meaningless, has no social construct supporting it.
11. So this general purpose platform for compute, communication and commerce -- just simply offering this platform as a creative canvas to the community --- that's the key. And if we can attract creative entrepreneurs -- then there is no reason that someone couldn't run a VOIP phone service from a Tron, or a virtual desktop, or run a machine learning / data science server service. You could just stream video from India or Philippines to expats for a subscription fee...etc
12. The business model of the core team is that the business of the core team is to provide this canvas. We will not compete with service providers who are operating outside a set of "utility applications" -- the utility applications will need to be explicitly defined and this will be done through the proposal system Crown inherited from Dash. This commitment of the core team not to be in the application business but to provide an application platform on which entrepreneurs can build businesses is another important feature discussed in the papers which I don't think anyone actually read...
If you think about the business opportunities on and around this sort of platform there are three broad opportunity sets: (1) node operator / service provider, (2) application developer, (3) onboarding & bridging. The first opportunity is just starting to be implemented; the second opportunity will become active once the API is defined and we will be starting to test it -- so this starts before the code update which pushes the API and other changes out to everyone; the third opportunity set is the one most often forgotten but essential -- how do people get money into Crown? how and why would a merchant adopt crown in a community? how do addresses get registered so that they can be used in the future to hold other assets as regulators understand how blockchains lower oversight and compliance costs? what are the opportunity to move different real world economic transactions and businesses onto the network over time?
So that's kind of the idea. General purpose compute first -- then probably communication, and then once we have shown reliability for those -- more and more commerce will come on board. And the value of the currency would be derived not from the cost of subsidized power in China -- but from the value in use to perform tasks which help people live their lives... pretty simple when you step back a little -- but the devil is in the details...
Hope that makes a little sense...
Just reposting this brilliant post about the intentions we have for the API we are working on.
I assume we'll be having a fair few first time visitors to this thread after today's price action so it would be good to keep people informed.
