I read some more of your document the other night and I really didn't like the section on creating and managing domains. Apart from anything I don't think it is workable.
The document states that users need to get a domain seed from a service provider. Why? And since anyone can be a service provider everyone will simply be their own service provider and provide their own seeds. Which makes the term "service provider" redundant since it ends up applying to everyone.
The document states that people populate the domain with applications bought from a service provider. Given that this is an open source project, I think you'll find that the vast majority of applications used will be downloaded for free by users and added to the domain. I hadn't realised that you expected to use multiple applications per domain either. And moreover the implication is that the user needs to buy the applications per domain. I.e. if they are working on three projects and want to have a time management application for all three projects, then they need to buy it three times. Somehow I don't see that being a popular selling model since people generally consider that if they buy an application then they get to use that application as much as they like, and not limited to a particular domain. It is also unenforceable. Only big companies who don't like negative publicity for piracy are likely to pay.
All in all the whole section seems focussed more on how Darwinet can be used to make money than on the technical and functional design of the system.
I appreciate that you want to make money out of Darwinet - which kind of makes me ask "what about my cut?" if I'm going to be spending my time writing a ton of code for the project. But realistically I think documenting the business model should be separated from documenting the design. And there doesn't seem to be much design in the document at all. Although there is a lot of definition of technology to be used, most of which I feel is impractical. The document says we need to use XML for the messaging. I just don't see any need for that at the Darwinet level. If applications choose to use XML documents that's fine and a design decision for the application. But I see no gain for the Darwinet engine.
So, in summary, I think we need a proper technical design document to work to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand you find the document containing contradicting and questionable statements. I will try to straighten them out soon.
Most important though: Darwinet is about freedom and privacy. But The section about selling applications and being service provider is there to ensure that we enable anyone to also trade and interact in commercial activities within Darwinet Domains! My vision is to make Darwinet as free and unlimited as humanly possible. And this includes anyone making business but on their own terms. Darwinet in it self should be as free as the internet!
The way for you and me to get food on our table from Darwinet is to find some app or service we can provide to Darwinet users. From Darwinet itself we get zip but the honor of having built it in the first place :)
And Yes - I sugest we write the technical design document as we go. I have not written one as so far I have focused on the motivation for Darwinet and the Services I'd like it to provide. In my mind I don't really care at the end of the day if the components making it tun is written in C on Linux, in Java for Andorid or Object C on OS X. As long as each Peer is able to interact with the others all fine with me.
That said - now lets focus on our proof of concept peer as a console application written in C++/C for Linux and Windows and see what comes out of that :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I read some more of your document the other night and I really didn't like the section on creating and managing domains. Apart from anything I don't think it is workable.
The document states that users need to get a domain seed from a service provider. Why? And since anyone can be a service provider everyone will simply be their own service provider and provide their own seeds. Which makes the term "service provider" redundant since it ends up applying to everyone.
The document states that people populate the domain with applications bought from a service provider. Given that this is an open source project, I think you'll find that the vast majority of applications used will be downloaded for free by users and added to the domain. I hadn't realised that you expected to use multiple applications per domain either. And moreover the implication is that the user needs to buy the applications per domain. I.e. if they are working on three projects and want to have a time management application for all three projects, then they need to buy it three times. Somehow I don't see that being a popular selling model since people generally consider that if they buy an application then they get to use that application as much as they like, and not limited to a particular domain. It is also unenforceable. Only big companies who don't like negative publicity for piracy are likely to pay.
All in all the whole section seems focussed more on how Darwinet can be used to make money than on the technical and functional design of the system.
I appreciate that you want to make money out of Darwinet - which kind of makes me ask "what about my cut?" if I'm going to be spending my time writing a ton of code for the project. But realistically I think documenting the business model should be separated from documenting the design. And there doesn't seem to be much design in the document at all. Although there is a lot of definition of technology to be used, most of which I feel is impractical. The document says we need to use XML for the messaging. I just don't see any need for that at the Darwinet level. If applications choose to use XML documents that's fine and a design decision for the application. But I see no gain for the Darwinet engine.
So, in summary, I think we need a proper technical design document to work to.
Thanks for great input Jontom!
I understand you find the document containing contradicting and questionable statements. I will try to straighten them out soon.
Most important though: Darwinet is about freedom and privacy. But The section about selling applications and being service provider is there to ensure that we enable anyone to also trade and interact in commercial activities within Darwinet Domains! My vision is to make Darwinet as free and unlimited as humanly possible. And this includes anyone making business but on their own terms. Darwinet in it self should be as free as the internet!
The way for you and me to get food on our table from Darwinet is to find some app or service we can provide to Darwinet users. From Darwinet itself we get zip but the honor of having built it in the first place :)
And Yes - I sugest we write the technical design document as we go. I have not written one as so far I have focused on the motivation for Darwinet and the Services I'd like it to provide. In my mind I don't really care at the end of the day if the components making it tun is written in C on Linux, in Java for Andorid or Object C on OS X. As long as each Peer is able to interact with the others all fine with me.
That said - now lets focus on our proof of concept peer as a console application written in C++/C for Linux and Windows and see what comes out of that :)