The original idea I had with Peernet of having a friends list of Peernet users that you could then chat with and request group/domain invites from has been rattling around in my head. It is something I really want, and at last I think I have found a way to fit it into Darwinet.
Open Domains
An open domain is one without a fixed user or node list. No invitation is required to join, although awareness of other users and nodes in the domain requires knowledge of at least one existing peer who can then introduce you to others.
Darwinet will locally store a list of known users and nodes as part of the domain, and of these the user marks some as "friends" or of special interest. On connecting to the domain, the Darwinet application will only contact those peers that are so marked as "friends", although it may use the wider list of contacts for general purpose searches and queries.
Such Open Domains allow organic social networking within the constraints of a particular application, although the contact details of other users in the domain can be used to send invites to other domains, both closed and open, and thus contact can be shared across multiple applications.
For example, user Adam meets user Betty in a poker game application's open domain. They chat while playing, become friends and Adam discovers that Betty likes surfing, so he invites her to a chat/discussion application's open domain where the topic is surfing. There Betty meets user Charlie and invites him to some other application/domain and so the users' social networks grow.
The key important points here are:
1) Anyone can join without invitation. This allows application providers to offer their product to everyone on the internet, to use their application in the same way as users can use any online application or join any other online community. The difference is that the application is true peer to peer without dependence on any servers maintained by the application provider.
2) The user and node lists do not form part of the domain information passed around because they are too large. If you are only interested in using the application with a limited number of other people, seeing whether they are online and ready to participate is difficult if their names are buried in a full list of domain members. Moreover bandwidth requirements mean that forming a full peer network with all other users and nodes currently on line is not practical. Users are only interested in interacting with a limited number of the domain members.
3) The peer network is fuzzy. Betty connects to and interacts with both Adam and Charlie, but they do not interact with each-other. Each user has their own unique peer network which does not need to match that of the peers in it. Also the peer network changes dynamically. If Adam and Betty are playing poker and David joins the table, then both Adam and Betty's peer networks will temporarily expand to include David. However if they do not add him as a friend, when David leaves the table he is removed from the Adam and Betty's peer networks, although his contact details may be kept for future use/identification.
Last edit: Kjell-Olov Högdahl 2013-03-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The original idea I had with Peernet of having a friends list of Peernet users that you could then chat with and request group/domain invites from has been rattling around in my head. It is something I really want, and at last I think I have found a way to fit it into Darwinet.
I like the Idea and I agree we must enable this feature in Darwinet networks.
An open domain is one without a fixed user or node list. No invitation is required to join, although awareness of other users and nodes in the domain requires knowledge of at least one existing peer who can then introduce you to others.
I sugest we enable the existing Domain concept to allow Open Domains. An open domain is one that allows anyone to join. We accomplish this by lowering the authorization requirement to none. Such a domain will allow any peer and any user to join. In this way the same Domain mechanism may be used to implement every Domain concept from "High restriction" (closed domain, publically invisible and invitaiton and authorization needed to join) to "Open" (publically visible, users and peers applies for membership and will always be granted membership).
Darwinet will locally store a list of known users and nodes as part of the domain, and of these the user marks some as "friends" or of special interest. On connecting to the domain, the Darwinet application will only contact those peers that are so marked as "friends", although it may use the wider list of contacts for general purpose searches and queries.
In my mind we reuse the MIV mechanism to store and share information about the Domain.
The Domain stores information about users, peers etc. in the Domain MIV in effect sharing the Domain information througout the Peers of the Domain.
We allow each user in a Domain to have a list of "Friends". The beauty of this is that this "Friend" concept is now available in any Domain. So you may have global friends in the Darwinet Domain. Or "poker friends" in a Poker Game application Domain etc. Combined with the "Domain Brdining" mechanism this could be a very powerful way to interconnect Darwinet Domains though the users social connections.
Such Open Domains allow organic social networking within the constraints of a particular application, although the contact details of other users in the domain can be used to send invites to other domains, both closed and open, and thus contact can be shared across multiple applications.
Yes! I propose we define a "Domain" to simply define a group of Users and Peers and rules of how to join, leave and Domain data access rules (MIV stored and shared). Combined with "Domain Bridging" we may enable a Poker Game application to bridge to e.g. the Global Darwinet Domain, other poker game application it knows of etc. Users may then access any appropriate "Friends" lists to roam for new friends (if this is the correct usage of the term "roam").
Figure: Think of the MIV as the P2P network eqvivalent of the central server data. With this view it is easy to see how to apply the MIV mechanism to accomplish the same stuff as a server based service would provide. In the Darwinet World we need to implement mechanism to allow finding Domains and applications of interest although there are no global "Adress" to query. Remember that P2P networks in general and Darwinet networks in particular may be totally closed and "invisible" to all but members. To open up Domains and allow the "cross domain" roaming for new friends or applications calls for a mechanism that does not compromise the security of the closed domains. Your "Friend" concept is one such mechanism. And if we build it into the Darwinet Domain handler as a concept we may control that it does not violate closed domain integrity.
For example, user Adam meets user Betty in a poker game application's open domain. They chat while playing, become friends and Adam discovers that Betty likes surfing, so he invites her to a chat/discussion application's open domain where the topic is surfing. There Betty meets user Charlie and invites him to some other application/domain and so the users' social networks grow.
Yes! One way to extend the "Friends" concept is that Adam and Betty creates a new Domain where they interact. Adam populates this Domain to with the Surf chat application and bridges it to the Surf chat domain. Betty as member of the "Adam/Betty" domain then gets access to the chat and the bridged Domain.
1) Anyone can join without invitation. This allows application providers to offer their product to everyone on the internet, to use their application in the same way as users can use any online application or join any other online community. The difference is that the application is true peer to peer without dependence on any servers maintained by the application provider.
yes. An Application Vendor may define a Darwinet Domain for their Application. If you install the Application you become a member of that Domain as user of the Application. Teh Vendor may also provide updates though the Application Domain MIV! Users then gets updates "in the mackgound" though the MIV synchronisation mechanism. Users may select to be publically visible in the Application Domain enabling other users of that application to find them and create new user Domains.
2) The user and node lists do not form part of the domain information passed around because they are too large. If you are only interested in using the application with a limited number of other people, seeing whether they are online and ready to participate is difficult if their names are buried in a full list of domain members. Moreover bandwidth requirements mean that forming a full peer network with all other users and nodes currently on line is not practical. Users are only interested in interacting with a limited number of the domain members.
You identify a key Issue with large P2P domains here. How do you enable very large Domains? In my mind we implement a delta roaming mechanism that alows data to "ripple" through the network until all Peers are in synch. Think of how ants or bees interact when they meet and exchange feromones that signals what is up. Or hos gossip travles between humans. Combined with a "RAID" mechanism for distributed storage of the MIV history and state we should be able to make large domains work!
3) The peer network is fuzzy. Betty connects to and interacts with both Adam and Charlie, but they do not interact with each-other. Each user has their own unique peer network which does not need to match that of the peers in it. Also the peer network changes dynamically. If Adam and Betty are playing poker and David joins the table, then both Adam and Betty's peer networks will temporarily expand to include David. However if they do not add him as a friend, when David leaves the table he is removed from the Adam and Betty's peer networks, although his contact details may be kept for future use/identification.
The game state is in the Domain MIV. The Domain handler controls members of the game and synchronization of the game state. The Poker Game Application may be bult to allow non-playing members that joins just to whatch the game.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
[quote]The Domain stores information about users, peers etc. in the Domain MIV in effect sharing the Domain information througout the Peers of the Domain.[/quote]
This isn't workable. Imagine a simple instant messaging application. With 1 million users. I'm sure Yahoo Messenger and other such apps have far more users than that even. Let's sya there is 1024 bytes data to be stored per user. Public key, node list with public keys, etc. When a new user joins the domain, they need to download the MIV before they can use the application. That's 1 GB download just for the user list. That would take HOURS!! Most users would just cancel the download and quit the app after just a minute or so. It's also unnecessary.
I fully agree that for other networks the domain should include the user and node information.
I also like your description of the ripple effect of updates, but I already anticipated that that was how the MIV deltas would work. It's inevitable when you want to keep numbers of nodes up to date and many of them will be offline at any time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The original idea I had with Peernet of having a friends list of Peernet users that you could then chat with and request group/domain invites from has been rattling around in my head. It is something I really want, and at last I think I have found a way to fit it into Darwinet.
Open Domains
An open domain is one without a fixed user or node list. No invitation is required to join, although awareness of other users and nodes in the domain requires knowledge of at least one existing peer who can then introduce you to others.
Darwinet will locally store a list of known users and nodes as part of the domain, and of these the user marks some as "friends" or of special interest. On connecting to the domain, the Darwinet application will only contact those peers that are so marked as "friends", although it may use the wider list of contacts for general purpose searches and queries.
Such Open Domains allow organic social networking within the constraints of a particular application, although the contact details of other users in the domain can be used to send invites to other domains, both closed and open, and thus contact can be shared across multiple applications.
For example, user Adam meets user Betty in a poker game application's open domain. They chat while playing, become friends and Adam discovers that Betty likes surfing, so he invites her to a chat/discussion application's open domain where the topic is surfing. There Betty meets user Charlie and invites him to some other application/domain and so the users' social networks grow.
The key important points here are:
1) Anyone can join without invitation. This allows application providers to offer their product to everyone on the internet, to use their application in the same way as users can use any online application or join any other online community. The difference is that the application is true peer to peer without dependence on any servers maintained by the application provider.
2) The user and node lists do not form part of the domain information passed around because they are too large. If you are only interested in using the application with a limited number of other people, seeing whether they are online and ready to participate is difficult if their names are buried in a full list of domain members. Moreover bandwidth requirements mean that forming a full peer network with all other users and nodes currently on line is not practical. Users are only interested in interacting with a limited number of the domain members.
3) The peer network is fuzzy. Betty connects to and interacts with both Adam and Charlie, but they do not interact with each-other. Each user has their own unique peer network which does not need to match that of the peers in it. Also the peer network changes dynamically. If Adam and Betty are playing poker and David joins the table, then both Adam and Betty's peer networks will temporarily expand to include David. However if they do not add him as a friend, when David leaves the table he is removed from the Adam and Betty's peer networks, although his contact details may be kept for future use/identification.
Last edit: Kjell-Olov Högdahl 2013-03-29
I like the Idea and I agree we must enable this feature in Darwinet networks.
I sugest we enable the existing Domain concept to allow Open Domains. An open domain is one that allows anyone to join. We accomplish this by lowering the authorization requirement to none. Such a domain will allow any peer and any user to join. In this way the same Domain mechanism may be used to implement every Domain concept from "High restriction" (closed domain, publically invisible and invitaiton and authorization needed to join) to "Open" (publically visible, users and peers applies for membership and will always be granted membership).
In my mind we reuse the MIV mechanism to store and share information about the Domain.
The Domain stores information about users, peers etc. in the Domain MIV in effect sharing the Domain information througout the Peers of the Domain.
We allow each user in a Domain to have a list of "Friends". The beauty of this is that this "Friend" concept is now available in any Domain. So you may have global friends in the Darwinet Domain. Or "poker friends" in a Poker Game application Domain etc. Combined with the "Domain Brdining" mechanism this could be a very powerful way to interconnect Darwinet Domains though the users social connections.
Yes! I propose we define a "Domain" to simply define a group of Users and Peers and rules of how to join, leave and Domain data access rules (MIV stored and shared). Combined with "Domain Bridging" we may enable a Poker Game application to bridge to e.g. the Global Darwinet Domain, other poker game application it knows of etc. Users may then access any appropriate "Friends" lists to roam for new friends (if this is the correct usage of the term "roam").
Figure: Think of the MIV as the P2P network eqvivalent of the central server data. With this view it is easy to see how to apply the MIV mechanism to accomplish the same stuff as a server based service would provide. In the Darwinet World we need to implement mechanism to allow finding Domains and applications of interest although there are no global "Adress" to query. Remember that P2P networks in general and Darwinet networks in particular may be totally closed and "invisible" to all but members. To open up Domains and allow the "cross domain" roaming for new friends or applications calls for a mechanism that does not compromise the security of the closed domains. Your "Friend" concept is one such mechanism. And if we build it into the Darwinet Domain handler as a concept we may control that it does not violate closed domain integrity.
Yes! One way to extend the "Friends" concept is that Adam and Betty creates a new Domain where they interact. Adam populates this Domain to with the Surf chat application and bridges it to the Surf chat domain. Betty as member of the "Adam/Betty" domain then gets access to the chat and the bridged Domain.
yes. An Application Vendor may define a Darwinet Domain for their Application. If you install the Application you become a member of that Domain as user of the Application. Teh Vendor may also provide updates though the Application Domain MIV! Users then gets updates "in the mackgound" though the MIV synchronisation mechanism. Users may select to be publically visible in the Application Domain enabling other users of that application to find them and create new user Domains.
You identify a key Issue with large P2P domains here. How do you enable very large Domains? In my mind we implement a delta roaming mechanism that alows data to "ripple" through the network until all Peers are in synch. Think of how ants or bees interact when they meet and exchange feromones that signals what is up. Or hos gossip travles between humans. Combined with a "RAID" mechanism for distributed storage of the MIV history and state we should be able to make large domains work!
In darwinet you create a new poker game as a Domain (See http://darwinet.sourceforge.net/TheDarwinetOpenP2PServiceCloudSpecification/#!Documents/exampleofonlinegamingapplicationindarwinet.htm).
The game state is in the Domain MIV. The Domain handler controls members of the game and synchronization of the game state. The Poker Game Application may be bult to allow non-playing members that joins just to whatch the game.
[quote]The Domain stores information about users, peers etc. in the Domain MIV in effect sharing the Domain information througout the Peers of the Domain.[/quote]
This isn't workable. Imagine a simple instant messaging application. With 1 million users. I'm sure Yahoo Messenger and other such apps have far more users than that even. Let's sya there is 1024 bytes data to be stored per user. Public key, node list with public keys, etc. When a new user joins the domain, they need to download the MIV before they can use the application. That's 1 GB download just for the user list. That would take HOURS!! Most users would just cancel the download and quit the app after just a minute or so. It's also unnecessary.
I fully agree that for other networks the domain should include the user and node information.
I also like your description of the ripple effect of updates, but I already anticipated that that was how the MIV deltas would work. It's inevitable when you want to keep numbers of nodes up to date and many of them will be offline at any time.