As mentioned in topic Darwinet for UN Millenium Development Goals Project we need to find a way to host Darwinet nodes "on the web" as opposed to as local clients. This enables a user to log in to a Darwinet Domain from e.g. a computer at an internet cafe. This is an anonymous device not owned by the user or any member of any Darwinet domain.
But this inly solves the problem of Web-browser access to a Darwinet Domain. The actual Peer data still needs a dedicated home at at least one node that is a member of a Darwinet Domain.
A user that does not own a device of her own has no physical device where to host a Peer.
The only solution as I see it now is to define a Darwinet Peer Hotel provider. This Host provides the physical storage of Peers. Now this idea may not be so bad after all. The contents of the data stored with this Hosted Peer are still protected as designed by the privacy mechanisms of Darwinet. And the Host provider may implicitly provide data storage the user is unable to provide on her own devices or on devices available otherwise in Darwinet domains.
For the UN related project mentioned above we may:
Design an HTML 5 application with an "in process" Darwinet engine. (Ok, in-process is a little awkward here but as an HTML 5 application it will really execute the Darwinet Engine within itself)
Define a Darwinet Peer Hotel (A Darwinet Service Provider).
I propose this is possible while keeping the internal Darwinet "service topology" intact. Only the location of where the code executes and what executes it differs. Peers still provide the Engine, Domain, View concept and exchanges and stores deltas as designed by the Darwinet network.
Exciting stuff this!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see why you have to embed the engine in the web page. The engine doesn't handle decryption of user/application data, the application, in this case the wep page app, does it. I am designing the engine to handle multiple connections for multiple users, apps, and domains. The original idea was that on a big shared server that users log onto, the engine is run as a system-wide daemon that all users/apps connect to. I don't see why you cannot just have the app written in HTML 5.
I also don't see why you are so keen on having an in-process engine. This has two huge flaws:
1) It isn't running if the app isn't running, meaning more node downtime, and slower startup on connection as the engine needs to download potentially huge amounts of information to catch up on current domain state.
2) Locking/concurrency issues if you have multiple apps being used on the same data within a single domain.
Also if you want a web page app with an in-process engine, the engine potentially needs to be restarted and then stopped on every access, which is slower and also means more network spam as the engine tries to contact peers every time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But I am aiming at making Darwinet a network definition connecting Peers that are not Desktops.
A mobile device may not allow an out-of-process Darwinet engine to be used the way we require it (application interface and background processing). iOS implements quire strong "sandboxing" so I opt for the need that such an app must use an in-process engine.
Aha! But that is what the MIV is for! Each App gets its own view of the MIV and the engine uses deltas to synhcronize them :)
Web-access comes from the need to provide Darwinet services also to those that does not own a Device of their own. The Peer must live somewhere and users may only have a web-browser at disposal to interact with the network.
Well, I sympathize with you struggling to understand why I come up with so seemingly strange notions for the design. But believe me, I am aiming at a very exciting goal here. So bear with me!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As mentioned in topic Darwinet for UN Millenium Development Goals Project we need to find a way to host Darwinet nodes "on the web" as opposed to as local clients. This enables a user to log in to a Darwinet Domain from e.g. a computer at an internet cafe. This is an anonymous device not owned by the user or any member of any Darwinet domain.
I have touched the subject in Web hosted Darwinet nodes
and Web server hosted Darwinet node
But this inly solves the problem of Web-browser access to a Darwinet Domain. The actual Peer data still needs a dedicated home at at least one node that is a member of a Darwinet Domain.
A user that does not own a device of her own has no physical device where to host a Peer.
The only solution as I see it now is to define a Darwinet Peer Hotel provider. This Host provides the physical storage of Peers. Now this idea may not be so bad after all. The contents of the data stored with this Hosted Peer are still protected as designed by the privacy mechanisms of Darwinet. And the Host provider may implicitly provide data storage the user is unable to provide on her own devices or on devices available otherwise in Darwinet domains.
For the UN related project mentioned above we may:
I propose this is possible while keeping the internal Darwinet "service topology" intact. Only the location of where the code executes and what executes it differs. Peers still provide the Engine, Domain, View concept and exchanges and stores deltas as designed by the Darwinet network.
Exciting stuff this!
I don't see why you have to embed the engine in the web page. The engine doesn't handle decryption of user/application data, the application, in this case the wep page app, does it. I am designing the engine to handle multiple connections for multiple users, apps, and domains. The original idea was that on a big shared server that users log onto, the engine is run as a system-wide daemon that all users/apps connect to. I don't see why you cannot just have the app written in HTML 5.
I also don't see why you are so keen on having an in-process engine. This has two huge flaws:
1) It isn't running if the app isn't running, meaning more node downtime, and slower startup on connection as the engine needs to download potentially huge amounts of information to catch up on current domain state.
2) Locking/concurrency issues if you have multiple apps being used on the same data within a single domain.
Also if you want a web page app with an in-process engine, the engine potentially needs to be restarted and then stopped on every access, which is slower and also means more network spam as the engine tries to contact peers every time.
I would agree if our aim is desktop environments.
But I am aiming at making Darwinet a network definition connecting Peers that are not Desktops.
Web-access comes from the need to provide Darwinet services also to those that does not own a Device of their own. The Peer must live somewhere and users may only have a web-browser at disposal to interact with the network.
Well, I sympathize with you struggling to understand why I come up with so seemingly strange notions for the design. But believe me, I am aiming at a very exciting goal here. So bear with me!