Trustroots Wiki - User contributions [en]

Nexus P2P trust network

2009-10-21T15:30:07Z

Matrixpoint: /* Dedicated Search engines? */

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

''I hadn't thought of it, but you are right.''

''Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who want to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.''

''As for persons who are sensitive about privacy, they can hide within a community. The community can create a profile which gains a reputation on the trust network based on how well they internally vouch for their own members.''

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

''A universal problem with P2P networks is that there is no guarantee that all records corresponding to a key will be found on any given attempt, especially when first connected when the DHT is only partially filled. (P2P file sharing networks take a few minutes to get up to speed). Redundancy does a lot to offset this weakness. The reliability is quite high, but not perfect. The positive side is that there is no censoring possible.''

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

''Yes, there needs to be an algorithm that gives more weight to references by those you highly trust, somewhat less weight to references by friends of those you highly trust and so on. A reference by someone with whom there is no prior trust relationship would carry little or no weight. There are trust metrics already well-established that take into account the various paths of trust between two entities.''

''I imagined that the result of a search would be a list of candidates (along with perhaps a thumbprint picture that could be part of the identity record or obtained from the profile), a link to the profile, and a trust ranking, and maybe a display of trust paths to this person. Clicking on a link would render a profile in a browser and as you say some magic might be needed to embed the trust info into the rendering.''

''Typically, the results of a P2P search are displayed as they come in over some seconds or minutes. Visually on the display, that would correspond to a growing list of entities, with possibly changing values of the trust measures as the results come in. This is not like what people are used to from a central database, and is one of the reasons why P2P networks have limited popularity. Anything we can do to improve on this would help popularity.''

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

''It might be possible to handle the rendering within the Nexus platform. (Java is known for it's vast range of libraries. There must be a rendering engine. Java can do almost anything.) Or, Nexus can fetch the html page, modify it, and then pipe it to the browser in some way. This would be a nice little piece of magic.''

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

''Possibly, a whole digital eco-system could spring up around this. That's fine with me. I like your concept of competing reference realms. I used to study genetic algorithms, and it's amazing what self-organized complexity that can spontaneously occur if you create the right kind of framework for that to happen. Incidentally, from the beginning we've kept the possibility in mind that this trust network could grow beyond hospex into bartering, etc.; anything requiring trust.''

''Great thoughts. Thanks!''

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T15:03:50Z

Matrixpoint: /* References */

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

''I hadn't thought of it, but you are right.

Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who want to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.

As for persons who are sensitive about privacy, they can hide within a community. The community can create a profile which gains a reputation on the trust network based on how well they internally vouch for their own members.''

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

''A universal problem with P2P networks is that there is no guarantee that all records corresponding to a key will be found on any given attempt, especially when first connected when the DHT is only partially filled. (P2P file sharing networks take a few minutes to get up to speed). Redundancy does a lot to offset this weakness. The reliability is quite high, but not perfect. The positive side is that there is no censoring possible.''

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

''Yes, there needs to be an algorithm that gives more weight to references by those you highly trust, somewhat less weight to references by friends of those you highly trust and so on. A reference by someone with whom there is no prior trust relationship would carry little or no weight. There are trust metrics already well-established that take into account the various paths of trust between two entities.''

''I imagined that the result of a search would be a list of candidates (along with perhaps a thumbprint picture that could be part of the identity record or obtained from the profile), a link to the profile, and a trust ranking, and maybe a display of trust paths to this person. Clicking on a link would render a profile in a browser and as you say some magic might be needed to embed the trust info into the rendering.''

''Typically, the results of a P2P search are displayed as they come in over some seconds or minutes. Visually on the display, that would correspond to a growing list of entities, with possibly changing values of the trust measures as the results come in. This is not like what people are used to from a central database, and is one of the reasons why P2P networks have limited popularity. Anything we can do to improve on this would help popularity.''

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

''It might be possible to handle the rendering within the Nexus platform. (Java is known for it's vast range of libraries. There must be a rendering engine. Java can do almost anything.) Or, Nexus can fetch the html page, modify it, and then pipe it to the browser in some way. This would be a nice little piece of magic.''

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

''Possibly, a whole digital eco-system could spring up around this. That's fine with me. I like your concept of competing reference realms. I used to study genetic algorithms, and it's amazing what self-organized complexity that can spontaneously occur if you create the right kind of framework for that to happen. Incidentally, from the beginning we've kept the possibility in mind that this trust network could grow beyond hospex into bartering, etc.; anything requiring trust.''

''Great thoughts. Thanks!''

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T15:02:11Z

Matrixpoint:

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

''I hadn't thought of it, but you are right.

Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who want to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.

As for persons who are sensitive about privacy, they can hide within a community. The community can create a profile which gains a reputation on the trust network based on how well they internally vouch for their own members.''

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

''A universal problem with P2P networks is that there is no guarantee that all records corresponding to a key will be found on any given attempt, especially when first connected when the DHT is only partially filled. (P2P file sharing networks take a few minutes to get up to speed). Redundancy does a lot to offset this weakness. The reliability is quite high, but not perfect. The positive side is that there is no censoring possible.''

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

''Yes, there needs to be an algorithm that gives more weight to references by those you highly trust, somewhat less weight to references by friends of those you highly trust and so on. A reference by someone with whom there is no prior trust relationship would carry little or no weight. There are trust metrics already well-established that take into account the various paths of trust between two entities.''

''I imagined that the result of a search would be a list of candidates (along with perhaps a thumbprint picture that could be part of the identity record or obtained from the profile), a link to the profile, and a trust ranking, and maybe a display of trust paths to this person. Clicking on a link would render a profile in a browser and as you say some magic might be needed to embed the trust info into the rendering.''

''Typically, the results of a P2P search are displayed as they come in over some seconds or minutes. Visually on the display, that would correspond to a growing list of entities, with possibly changing values of the trust measures as the results come in. This is not like what people are used to from a central database, and is one of the reasons why P2P networks have limited popularity. Anything we can do to improve on this would help popularity.''

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

''It might be possible to handle the rendering within the Nexus platform. (Java is known for it's vast range of libraries. There must be a rendering engine. Java can do almost anything.) Or, Nexus can fetch the html page, modify it, and then pipe it to the browser in some way. This would be a nice little piece of magic.''

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

''Possibly, a whole digital eco-system could spring up around this. That's fine with me. Incidentally, from the beginning we've kept the possibility in mind that this trust network could grow beyond hospex into bartering, etc.; anything requiring trust. I like your concept of competing reference realms. I used to study genetic algorithms, and it's amazing what self-organized complexity that can spontaneously occur if you create the right kind of framework for that to happen.''

''Great thoughts. Thanks!''

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T14:36:20Z

Matrixpoint:

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

''I hadn't thought of it, but you are right.

Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who ''want'' to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.

As for persons who are sensitive about privacy, they can hide within a community. The community can create a profile which gains a reputation on the trust network based on how well they internally vouch for their own members.''

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

''A universal problem with P2P networks is that there is no guarantee that all records corresponding to a key will be found on any given attempt, especially when first connected when the DHT is only partially filled. (P2P file sharing networks take a few minutes to get up to speed). Redundancy does a lot to offset this weakness. The reliability is quite high, but not perfect. The positive side is that there is no censoring possible.''

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T14:27:38Z

Matrixpoint: /* Good point! */

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

=====Good point!=====
I hadn't thought of it, but you are right.

Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who ''want'' to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.

As for persons who are sensitive about privacy, they can hide within a community. The community can create a profile which gains a reputation on the trust network based on how well they internally vouch for their own members.

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T14:23:34Z

Matrixpoint: /* Good point! */

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

=====Good point!=====
I hadn't thought of it, but you are right.

Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who ''want'' to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T14:23:04Z

Matrixpoint: /* Dedicated Search engines? */

''This is a preliminary draft description of the'' '''Nexus P2P trust network'''.

After a long search for an easily deploy-able existing solution, I did not find one and so began developing one. So far, I am the only developer working on it. I'm about half-way through.

==Design goals==

===Hardware configuration===
Operates on a swarm of networked personal computers, like existing file-sharing networks. Minimal or no corporate server involvement. The heart of the system is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like network. There is an unavoidable trade-off of speed vs. privacy and immunity from control. I opted for the later, but will try to optimize speed.

===License===
Free and open software. I'm not familiar with licenses, but am leaning toward GPL2. ''Could use some advice''.

===Software platform===
Should be as universal as possible. Considered a Firefox browser add-on, but went with Java because of the availability of the UDP data protocol and many other advantages.

===Functionality===
Functionality limited to searching for and evaluating the reputation of individuals or communities. Usable from a GUI or XML-RPC interface.

==Status==
The heart of '''Nexus''' is a [http://en.wikipedia.org/wiki/Kademlia Kademlia]-like distributed P2P network and is awaiting large scale testing. Data can be stored and retrieved from it. One or more layers will be built on top of it to complete the functionality.

I would like to set this up for community development once a license is chosen and if anyone else wants to help.

[[User:Matrixpoint|Matrixpoint]] 12:42, 20 October 2009 (UTC)

[[Category:P2P Hospitality]]

==Questions==
===Intro===
Yeah, things are moving!

Some questions I have:

===Where do you want to store member profiles?===
A fundamental design specification is to keep Nexus as lightweight and as fast as possible. An ''identity record'' on Nexus would be not much more than a handle, a set of descriptive tags, a link to a profile on a social website, an expiration date, a public encryption key, and a digital signature.

If applying the public key to the record (less the signature) produces a match to the signature, then it is confirmed that the owner of the private key corresponding to the public key is the individual who created the record. This step is automatically performed by Nexus.

The website profile would include a means of contact (such as email). If an email containing some random data (or just a unique message) is encrypted with the public key and sent to the owner of the profile, and that person responds with an email containing the random data, then the original sender now has a reliable means of contacting the true owner of the Nexus record and has the option of having a private (encrypted) communication with that owner. That owner can confirm that the profile used to contact him is legitimate.

Typically, the owner of a Nexus record would have many profiles on different social websites. That owner would pick one of them to represent his identity to Nexus. He could actually create several independent Nexus identities if he chooses.

The essence of a virtual identity on Nexus is the public key. It can be used to reliably connect to the real person behind the identity as long as that person keeps his private key secret. A virtual identity starts out with no reputation and must acquire one over time. This is done through a second kind of record, a ''reference record''.

A Nexus reference record contains at least a rating code but perhaps also a text reference. It also contains the handles and public keys of the owner of the reference and the object of the reference, an expiration date, and a signature made from the owner's private key.

Each record stored in Nexus has a search key (probably invisible to the end-user). A search key can have multiple records associated with it. Identity records can be retrieved with keys like ''identity:handle'', reference records with keys like ''reference-for:handle'' or ''reference-by:handle''. Several different identities might use the same handle, so a handle is only a convenient approximation to an identity. The retrieved references are matched to the correct identities using the public keys.

There are also ''tag records'' in Nexus, used for searching for identities using descriptive tags. The design of this could go several ways, but the basic idea is that these records only contain handles.

So, all of the data that is moved and stored on Nexus is relatively small in size. No web pages, no pictures or other media. This is important for speed especially since there is much redundancy.

Please note that I have not actually implemented the layer that manages structured records yet. What is currently implemented can only store (with redundancy) and retrieve unstructured data records using a search key. But the lower-level mechanisms for bootstrapping and maintaining a distributed network with many nodes frequently entering and leaving is now implemented.

===Will there be redundant copies on different machines, or will each profile live on one machine?===
There will be redundant copies of all nexus records, probably about 20 live (online) copies. No profile information is stored. If the owner of a nexus identity record wants to change the link to his profile, he must create a new identity record. All records on nexus have an expiration date. So two competing records referring to the same identity are resolved by the most recent update. It is up to the owner of an identity to periodically refresh or update his identity and the references he creates. He can specify the lifetime of his records, but there would be a system-wide maximum time limit.

===What about people switching off their home computers - will that disrupt anything?===
The Nexus network frequently refreshes itself. If one of the twenty copies of a record goes offline, it would soon be automatically replaced. The current version does ''not'' store any records offline. It is very dynamic, almost like a living thing. In the even of a total simultaneous internet failure, or the unlikely event that all twenty copies would disappear before the next refresh cycle, the worst consequence is that the searchable data is gone until the owner goes online and refreshes it (automatically). For this application, I don't think that's very serious. It would be easy enough to provide for local storage of records on multiple PC's, but it would be interesting to try to avoid this.

Right now, the only things locally stored between sessions are:
*a list of IP addresses to enable quick reconnection to the network. This list is updated every session with known active nodes.
*the identity record and reference records created by the local node owner.
*the public/private key pair of the owner.

===How can I know that the network node I'm currently connected to delivers authentic information?===
The Nexus network is a swarm of interconnected computers. Anyone who can run a java program on their computer can become a node in the network if they have even one IP address of another live node. The could get this in a number of ways:
*from the saved list of nodes from the last session
*someone gives them a live node address via email, chat, web page, etc.
*automatically from a range of dyndns.com domain names with a predetermined pattern like nexus-001.dyndns.com, nexus-002.dyndns.com, etc. that the Nexus software can automatically scan. Some members of the network would have to set up one of the domains for the benefit of the whole network. But this measure would only be needed for first contact or after a long absence.

One of the unique features of Nexus is that the hash codes of its DHT (Dynamic Hash Table) are computed from the IP addresses of the nodes. This is a protection against manipulation of the network, such as introducing a split in the node grid.

But the data itself can always be verified by making use of the public encryption keys and digital signatures that are part of each identity or reference record.

The network could allow for access through an XML-RPC port on nodes with known domain names (such as from dyndns.com), but they would not be peers in the network, and could probably be tricked by an impostor. But in the end the data acquired would not stand up to validity checks.

I'm not sure it's a good idea to allow such access to the network. An individual node might be overwhelmed with requests (unless the requests were automatically dished off to other nodes). I would rather have all users of Nexus also be peer nodes. Since the Nexus platform is Java, the big hospex websites could participate in Nexus by embedding a Java applet in one of their web pages (making each of their users a node of Nexus) (this is another reason to keep Nexus very lightweight), or else by creating a PHP version of Nexus to run on their server, or at least making it available to download.

===How does a search work? Where do you want to store the search index?===
As explained above, there would be no centralized index residing on a server somewhere. The index would be distributed across the Nexus network in the form of ''tag records''.

This is probably the most challenging and interesting part of the project. It is really still an open question in P2P network technology. I haven't worked out the details yet but I have several ideas.

There are some fairly good open-source implementations in use such as [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] that we could imitate. P2P range searches are the most challenging, and they are an active area of academic research already producing usable results. A few recent papers are available on the internet.

In keeping with the minimalist philosophy of this project, I suggest that searching should be highly structured according to a standardized format suitable for hospex, which would make implementation much easier. But innovative ideas are welcome.

====Dedicated Search engines?====
If I understand right, there is nothing that would stop a bigger player (such as Google) to crawl all the records and store them on a central server, with a search index, and associated with the profile information on the social networks - if this profile information is publicly available. Maybe that is not what you intended, but this would be a possible solution for search: Have one or more services that offer search features.

====Good point!====
I hadn't thought of it, but you are right.

Although the 3M's talked a lot about privacy and dark nets, this particular project is for people who ''want'' to be found (up to the level of detail provided in their profile), and don't mind being the subject of references. So there's no need to protect the network even from Google. Third-party server-based searching would enhance the network, providing speed and caching, and reducing the network load. But I would want to design the network so that it ''could'' function completely independently of any third-party server.

===References===
If I leave a negative reference to someone, how can I be sure that it will be displayed on this person's profile? And, how can you prevent anonymous people from leaving fake negative references?

I think the magic needs to happen at the moment that the profile is rendered: The system will have some rules to find those references that are relevant to the visitor, and then decorate the social network profile with this additional information.

This means: Either the social network where you created your account needs to be aware of Nexus, or you need to view the profile information through another service that adds the Nexus information - which can be a Firefox extension, or a website.

There could be "reference realms", their purpose being to decide which references are relevant and which are not. In addition, these entities could offer services similar to couchsurfing's MDST. The difference being that you can switch to a different reference realm if you feel they do a bad job.

===Conclusion===
Basically, I would like to see answered all the questions I posted on [[Decentralized networks]].

Each time when I thought myself about decentralized networks, it was these questions that stopped me.

Thanks!
-- [[User:Lemon-head|Lemon-head]] 22:17, 20 October 2009 (UTC)

Thanks for your interest! [[User:Matrixpoint|Matrixpoint]] 12:01, 21 October 2009 (UTC)

Nexus P2P trust network

2009-10-21T12:01:30Z

Matrixpoint: /* Questions */

Drupal Hospex Features

2009-10-21T07:23:33Z

Matrixpoint:

'''Drupal''' is a versatile [[free software]] content management system. It has quite a bit of social network functionality in the form of modules.

On [[BeWelcome]] there have been some calls to explore the possibilities of Drupal as an alternative to the home-grown BW-Rox platform that the network currently runs on. More generally speaking, Drupal is a possible option for any initiative to set up a new social network.

This page is adapted from [http://www.bevolunteer.org/wiki/Drupal], but unlike the source page, this article should be less about BeWelcome and more about the general idea of using Drupal for hospex purposes.

While a lot can be done with existing modules, it will be interesting to see where it makes sense or is necessary to have dedicated new modules built for hospex purposes.

Some of this article will be puzzling for people who don't know Drupal lingo. If you (yes, you!) feel like it, you can add links and explanations where they make sense.

== Requirements ==
We'd like to have user profiles, (location-based) member search, messages between members, trust links between members (references, friend links etc), and general community features such as groups, events, wiki-like editing etc.

Nice to have would be [[Decentralized networks|decentralization]] features, where different sites can interact with each other. Or even [[P2P]], but that would better be solved by something else (not Drupal).

Other nice-to-haves are couch/location objects that are independent from member profiles: One member can have more than one couch/location, and a group of members can share the responsibility for a couch/location (such as, in a shared flat. The pros and cons of that can be debated, but it's nice to have the technical possibility.

== User profiles and couches/locations ==

Drupal has a built-in user and profile system that allows for arbitrary custom fields, user avatar images etc. If that is not enough, the [http://drupal.org/project/content_profile Content Profile module] allows to unleash the full powers of the famous [http://drupal.org/project/content_profile Content Construction Kit ("CCK")].

A separate node type "couch" or "location" or "shared place" could be created and connected to user profiles via node reference or user reference.

== Location features ==
Drupal has a bunch of location modules working with CCK, Google Maps, etc.

See also http://www.openstreetmap.org (have not checked this link, it was in the wiki page on BW)

== Searching members and couches ==
Drupal core has a built-in search that searches everything (users, nodes, etc). More powerful and customized things are possible with [http://drupal.org/project/views Views] in combination with one of the location modules - but still needs to be explored.

It can make sense to write a ''custom search module'', for a better performance and flexibility, and so that site owners don't have the trouble of customization. This custom module could even define a custom view (based on Views module)

== Messages between Members ==
Need to check existing modules.

== Menu / Navigation ==
Basically, I don't see any technical limitations for this. The Drupal menu system + [http://drupal.org/project/menu_block Menu Blocks] module are usually sufficient, and some custom functionality can be implemented where this is not enough.

Admin links: The nice thing with Drupal's menu system is that it filters out links to pages that you are not allowed to see. So, admin links can simply be added in the normal menu.

== Multi-language features ==
Drupal has a lot of language features already built-in (core locale module). You can get more with the [http://drupal.org/project/i18n Internationalization ("i18n") module] and a bunch of other extra modules.

=== Translated content (nodes) ===
If you want to translate a node, Drupal creates a new node for each language version.

=== Translated text ===
Drupal, similar to WordPress, has a translation function used inside core and module code, used this way:

t('Please translate this piece of text');

Consequence: If you change one letter of this text, all the translations need to be re-done. And, if two texts are the same in the code, the translations will also be the same - even if the context is different.

The BW system works differently, because the translation function does not get the English string as an argument, but a keyword. In some way this is more flexible, because you can have different keywords for two texts that might be the same in English, but different in Russian. And, you can change the English translation without flushing all other translations, and without changing the code. On the other hand, if you implement a new page you always have to add some english translations, otherwise it will look horribly broken.

=== Interface for translators ===
The current platform running [[BeWelcome]] has some nice features for translators, where translation links are placed directly in the content. The BW system does work even if the text to translate is in a html tag attribute (such as, an image '''alt''' attribute, or a link '''title''' attribute - the link is placed somewhere where it doesn't break the layout.

Drupal has some similar features, but I have not checked out how they work exactly. Would be a good idea to do some research.

== Trust links / Friend links / References ==
Modules to check for friend links:
* http://drupal.org/project/drupal_universal_relation_api
* http://drupal.org/project/user_relationships
* http://drupal.org/project/friendlist

References could be modeled as comments, but maybe it's better to have a dedicated custom module for that.

== Other features ==

=== Groups ===
Check the "organic groups" module.

=== Forum ===
Ideally this should work together with "groups".. or for smaller sites it can make sense to have one big forum.

Check the "Advanced Forum" module.

=== Wiki ===
Check http://drupal.org/project/wikitools and a bunch of other wiki-related modules.

=== Chat ===
Check out the different available modules

=== Blog (for users and groups) ===
Site-wide blogs are easily possible with Drupal. User blogs are possible with the blog module (shipped with core). I'm sure that group blogs are possible with some contrib module..

=== Galleries ===
Usually you will make each picture node with filefield, and with any number of extra fields you want, plus comments. OR you can make each node have a collection of pictures, using flexifield or just multiple imagefields. Or make a custom data structure for that (but why?)

There is a bunch of modules to make this easier for you and that provide different ways to browse these pictures. Some of them based on Views. And if that is not enough, a custom module can make everything possible.

== Customized pages and forms ==
Sometimes we want to have a page or a form (such as, user profiles, or a signup form, etc) almost exactly like it is delivered by Drupal + contributed modules, but we want to change some tiny bits: For instance, add an option to the signup form to sign up for specific groups, etc. Or disable some fields. Or, split the profile page up to several different pages.

Luckily, this is all possible by creating custom modules! You can grab the data for generating a form or a page, modify it, and let Drupal render the modified form. Or you can intercept the usual process of rendering a page, do your modifications, and give back to Drupal to do the rest. The nice thing is, you only implement what you want to change, and leave the rest to Drupal core + contrib.

And of course, you can theme every bit of a Drupal page. You can even do a lot of the above mentioned customizations with themes alone, but beware! This can bloat your theme and makes it hard to provide alternative themes.

== Migration (Import / Export) ==
Drupal does have various import and export features to import data from other platforms.

== Release Management ==

(written from a BW-Rox perspective - please adapt)

Right now release management in BW is based on SVN. Most changes live in the code, so it's easy to track things via SVN, and a release is mostly code.

DB changes are done via dbupdate.php - which is not the nicest way to do it, but it keeps things more or less transparent by only looking at SVN.

=== Problem: How to deploy configuration changes? ===

Drupal works quite differently, as a lot of things happen in the DB, and will thus not show up on SVN. Releasing a new version will mean both changes to the code (CSS files, theme templates, modules), and changes in the DB via the admin backend. This makes things a bit more difficult and less transparent for developers who want to keep track of things via SVN.

And quite often you get heavy dependencies of DB and code - for instance, if template files refer to content type names that only exist in the DB.

=== Solution: Custom modules instead of admin configuration ===

It is possible to define a lot of stuff in Drupal in the code, instead of the DB, via custom modules. I would very much vote for this option. It requires some Drupal expertise, though.

==Links==
* [http://www.bewelcome.org/forums/s630?sidTB=OZUdxsHBu7pWxdTf6KfFrqYPf9c Technical alternatives: bw.rox, drupal and whatever]
* [http://bw-drupal.midsch.net/node/34 Drupallinks and Tutorials]

[[Category:P2P_Hospitality]]

P2P Hospitality initiatives and proposals

2009-10-21T07:22:24Z

Matrixpoint: /* 3M's Brainstorming notes */

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, such as this [[P2P Resources | P2P resources page]]. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy. For example, see the [[Drupal_Hospex_Features | Drupal hospex features]] page.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. A Java-based solution named [[Nexus P2P trust network | Nexus]] is under development.

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A Decentralized networks discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

P2P Hospitality initiatives and proposals

2009-10-21T07:20:29Z

Matrixpoint:

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, such as this [[P2P Resources | P2P resources page]]. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy. See this [[Drupal_Hospex_Features | analysis]] of hospex features in Drupal.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. A Java-based solution named [[Nexus P2P trust network | Nexus]] is under development.

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A Decentralized networks discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

Nexus P2P trust network

2009-10-20T12:58:15Z

Matrixpoint: /* Status */

Nexus P2P trust network

2009-10-20T12:57:31Z

Matrixpoint: /* Status */

Nexus P2P trust network

2009-10-20T12:42:46Z

Matrixpoint: Created page with '''This is a preliminary draft description of the'' '''Nexus P2P trust network'''. After a long search for an easily deploy-able existing solution, I did not find one and so bega…'

P2P Resources

2009-10-19T23:04:31Z

Matrixpoint:

==General information==
===The Foundation for P2P Alternatives===
[http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki]

[http://blog.p2pfoundation.net/ P2P Foundation blog]

[http://p2pfoundation.ning.com/ P2P Foundation ning social website]

The P2P foundation is probably the best resource for information about the Peer-to-Peer movement. The wiki has articles covering many subjects such as Governance, Business, Design, Manufacturing, Production, Energy, Money, Politics, Spirituality, Technology.

===WatchUsNow film===
The [http://watch.usnowfilm.com/subtitled WatchUsNow film] is a documentary examining the impact of the social web on society. Couchsurfing is covered, along with P2P-related examples.

===Life Inc.===
[http://vimeo.com/4655092 Life Inc. The Movie] is a short video version of the best selling book by Douglass Rushkoff. Great insights into the value of decentralization to our society.

===Daemon: Bot-mediated reality talk===
Daniel Suarez, author of the best selling techno-thriller ''[http://thedaemon.com/ Daemon]'' gave an interesting [http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality talk] at the Long Now Foundation. It makes us take decentralization and privacy seriously.

==Hardware/Software platforms==
===Ning===
[http://www.ning.com/ Ning] is a ready-to-go professionally run (not open-source) site that provides the tools to quickly set up a fully-functional customizable social web site. It might be a good interim solution for communities who just want a quick alternative to the big sites.

===Noserub===
[http://noserub.com Noserub] is an open-source social web site that can be set up on a single PC (configured as a server) or on a server. It aggregates user activity from any other Noserub sites or popular big social web sites that the user has an account on. Besides being convenient as an aggregator, it has a big privacy advantage in that the user has potentially much more control over his data (profile, messages, friend connections).

A demonstration (and practically useful) implementation of Noserub is [http://identoo.com Identoo]. You can open an account there to test it's features.

A drawback is that Noserub doesn't yet have built-in groups, but they are in the works for future release. Noserub only has a handful of part-time developers, so progress can be slow.

===RetroShare===
[http://retroshare.sourceforge.net/ RetroShare] is an open-source P2P network with a strong emphasis on privacy. It's actually closer to F2F (Friend-to-Friend), meant to be very private.

===Open-source file-sharing===

We are not really interested in file sharing ''per se'', but the file sharing community has led the way technically with P2P and privacy solutions, so we may be able to borrow some techniques. Here is a list of noteworthy examples:

*[http://www.emule-project.net/home/perl/general.cgi?l=1 eMule]
*[http://oneswarm.cs.washington.edu/ OneSwarm]
*[http://anomos.info/ Anomos]
*[http://en.wikipedia.org/wiki/Anonet Anonet]
*[http://en.wikipedia.org/wiki/ANts_P2P ANts]
*[http://gnunet.org/ Gnunet]
*[http://en.wikipedia.org/wiki/I2P I2P]
*[http://www.lifesocial.org/ Lifesocial]
*[http://allmydata.org/trac/tahoe Tahoe]

===Wuala===
[http://www.wuala.com/ Wuala] is not open-source, but has an advanced and professional-quality partly-P2P file storage system. It has some nice privacy and social features.

===Portable apps===
[http://portableapps.com/ Portable Apps] is an open-source solution which allows a user to take not only their data, but their applications with them when they travel on a USB stick. This has implications for P2P hospitality. Besides the general convenience for travelers, our proposed P2P trust network would probably have a private identity key. You could take not only the key, but the P2P trust network software itself on the road with you, making it easier to use from any PC.

[http://www.lupopensuite.com/ Lupo PenSuite] is another portability solution which has a long list of [http://www.lupopensuite.com/a-internet.htm portable apps].

===Popeye adaptive grid network===
[http://www.ist-popeye.eu/ Popeye] is an open-source product of academia supported by the EU. Over two years they developed a working demo. Computers in physical proximity automatically form a network which adapts to nodes moving, entering and leaving, while providing file sharing, messaging, voting, etc., services useful to a working group. Includes a video of a real-world demonstration.

==Tools==
===Zembly===
[http://zembly.com/ Zembly] is a tool for creating widgets for some of the big social sites. Could help get hospitality-specific apps into them.

===Overlay Weaver===
[http://overlayweaver.sourceforge.net/ Overlay Weaver] is a tool for designing and testing overlay networks like [http://en.wikipedia.org/wiki/Kademlia Kademlia], which are used in many P2P systems.

[[Category:P2P Hospitality]]

P2P Resources

2009-10-19T19:35:36Z

Matrixpoint: /* Daemon: Bot-mediated reality talk */

==General information==
===The Foundation for P2P Alternatives===
[http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki]

[http://blog.p2pfoundation.net/ P2P Foundation blog]

[http://p2pfoundation.ning.com/ P2P Foundation ning social website]

The P2P foundation is probably the best resource for information about the Peer-to-Peer movement. The wiki has articles covering many subjects such as Governance, Business, Design, Manufacturing, Production, Energy, Money, Politics, Spirituality, Technology.

===WatchUsNow film===
The [http://watch.usnowfilm.com/subtitled WatchUsNow film] is a documentary examining the impact of the social web on society. Couchsurfing is covered, along with P2P-related examples.

===Life Inc.===
[http://vimeo.com/4655092 Life Inc. The Movie] is a short video version of the best selling book by Douglass Rushkoff. Great insights into the value of decentralization to our society.

===Daemon: Bot-mediated reality talk===
Daniel Suarez, author of the best selling techno-thriller ''[http://thedaemon.com/ Daemon]'' gave an interesting [http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality talk] at the Long Now Foundation. It makes us take decentralization and privacy seriously.

==Hardware/Software platforms==
===Ning===
[http://www.ning.com/ Ning] is a ready-to-go professionally run (not open-source) site that provides the tools to quickly set up a fully-functional customizable social web site. It might be a good interim solution for communities who just want a quick alternative to the big sites.

===Noserub===
[http://noserub.com Noserub] is an open-source social web site that can be set up on a single PC (configured as a server) or on a server. It aggregates user activity from any other Noserub sites or popular big social web sites that the user has an account on. Besides being convenient as an aggregator, it has a big privacy advantage in that the user has potentially much more control over his data (profile, messages, friend connections).

A demonstration (and practically useful) implementation of Noserub is [http://identoo.com Identoo]. You can open an account there to test it's features.

A drawback is that Noserub doesn't yet have built-in groups, but they are in the works for future release. Noserub only has a handful of part-time developers, so progress can be slow.

===RetroShare===
[http://retroshare.sourceforge.net/ RetroShare] is an open-source P2P network with a strong emphasis on privacy. It's actually closer to F2F (Friend-to-Friend), meant to be very private. Development is more active and it is more socially oriented than the P2P [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] file sharing network.

===Open-source file-sharing===

We are not really interested in file sharing ''per se'', but the file sharing community has led the way technically with P2P and privacy solutions, so we may be able to borrow some techniques. Here is a list of noteworthy examples:

*[http://oneswarm.cs.washington.edu/ OneSwarm]
*[http://anomos.info/ Anomos]
*[http://en.wikipedia.org/wiki/Anonet Anonet]
*[http://en.wikipedia.org/wiki/ANts_P2P ANts]
*[http://gnunet.org/ Gnunet]
*[http://en.wikipedia.org/wiki/I2P I2P]
*[http://www.lifesocial.org/ Lifesocial]
*[http://allmydata.org/trac/tahoe Tahoe]

===Wuala===
[http://www.wuala.com/ Wuala] is not open-source, but has an advanced and professional-quality partly-P2P file storage system. It has some nice privacy and social features.

===Portable apps===
[http://portableapps.com/ Portable Apps] is an open-source solution which allows a user to take not only their data, but their applications with them when they travel on a USB stick. This has implications for P2P hospitality. Besides the general convenience for travelers, our proposed P2P trust network would probably have a private identity key. You could take not only the key, but the P2P trust network software itself on the road with you, making it easier to use from any PC.

[http://www.lupopensuite.com/ Lupo PenSuite] is another portability solution which has a long list of [http://www.lupopensuite.com/a-internet.htm portable apps].

===Popeye adaptive grid network===
[http://www.ist-popeye.eu/ Popeye] is an open-source product of academia supported by the EU. Over two years they developed a working demo. Computers in physical proximity automatically form a network which adapts to nodes moving, entering and leaving, while providing file sharing, messaging, voting, etc., services useful to a working group. Includes a video of a real-world demonstration.

==Tools==
===Zembly===
[http://zembly.com/ Zembly] is a tool for creating widgets for some of the big social sites. Could help get hospitality-specific apps into them.

===Overlay Weaver===
[http://overlayweaver.sourceforge.net/ Overlay Weaver] is a tool for designing and testing overlay networks like [http://en.wikipedia.org/wiki/Kademlia Kademlia], which are used in many P2P systems.

[[Category:P2P Hospitality]]

P2P Resources

2009-10-19T19:26:25Z

Matrixpoint:

==General information==
===The Foundation for P2P Alternatives===
[http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki]

[http://blog.p2pfoundation.net/ P2P Foundation blog]

[http://p2pfoundation.ning.com/ P2P Foundation ning social website]

The P2P foundation is probably the best resource for information about the Peer-to-Peer movement. The wiki has articles covering many subjects such as Governance, Business, Design, Manufacturing, Production, Energy, Money, Politics, Spirituality, Technology.

===WatchUsNow film===
The [http://watch.usnowfilm.com/subtitled WatchUsNow film] is a documentary examining the impact of the social web on society. Couchsurfing is covered, along with P2P-related examples.

===Life Inc.===
[http://vimeo.com/4655092 Life Inc. The Movie] is a short video version of the best selling book by Douglass Rushkoff. Great insights into the value of decentralization to our society.

===Daemon: Bot-mediated reality talk===
Daniel Suarez, author of the best selling techno-thriller Daemon gave an interesting [http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality talk] at the Long Now Foundation. It makes us take decentralization and privacy seriously.

==Hardware/Software platforms==
===Ning===
[http://www.ning.com/ Ning] is a ready-to-go professionally run (not open-source) site that provides the tools to quickly set up a fully-functional customizable social web site. It might be a good interim solution for communities who just want a quick alternative to the big sites.

===Noserub===
[http://noserub.com Noserub] is an open-source social web site that can be set up on a single PC (configured as a server) or on a server. It aggregates user activity from any other Noserub sites or popular big social web sites that the user has an account on. Besides being convenient as an aggregator, it has a big privacy advantage in that the user has potentially much more control over his data (profile, messages, friend connections).

A demonstration (and practically useful) implementation of Noserub is [http://identoo.com Identoo]. You can open an account there to test it's features.

A drawback is that Noserub doesn't yet have built-in groups, but they are in the works for future release. Noserub only has a handful of part-time developers, so progress can be slow.

===RetroShare===
[http://retroshare.sourceforge.net/ RetroShare] is an open-source P2P network with a strong emphasis on privacy. It's actually closer to F2F (Friend-to-Friend), meant to be very private. Development is more active and it is more socially oriented than the P2P [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] file sharing network.

===Open-source file-sharing===

We are not really interested in file sharing ''per se'', but the file sharing community has led the way technically with P2P and privacy solutions, so we may be able to borrow some techniques. Here is a list of noteworthy examples:

*[http://oneswarm.cs.washington.edu/ OneSwarm]
*[http://anomos.info/ Anomos]
*[http://en.wikipedia.org/wiki/Anonet Anonet]
*[http://en.wikipedia.org/wiki/ANts_P2P ANts]
*[http://gnunet.org/ Gnunet]
*[http://en.wikipedia.org/wiki/I2P I2P]
*[http://www.lifesocial.org/ Lifesocial]
*[http://allmydata.org/trac/tahoe Tahoe]

===Wuala===
[http://www.wuala.com/ Wuala] is not open-source, but has an advanced and professional-quality partly-P2P file storage system. It has some nice privacy and social features.

===Portable apps===
[http://portableapps.com/ Portable Apps] is an open-source solution which allows a user to take not only their data, but their applications with them when they travel on a USB stick. This has implications for P2P hospitality. Besides the general convenience for travelers, our proposed P2P trust network would probably have a private identity key. You could take not only the key, but the P2P trust network software itself on the road with you, making it easier to use from any PC.

[http://www.lupopensuite.com/ Lupo PenSuite] is another portability solution which has a long list of [http://www.lupopensuite.com/a-internet.htm portable apps].

===Popeye adaptive grid network===
[http://www.ist-popeye.eu/ Popeye] is an open-source product of academia supported by the EU. Over two years they developed a working demo. Computers in physical proximity automatically form a network which adapts to nodes moving, entering and leaving, while providing file sharing, messaging, voting, etc., services useful to a working group. Includes a video of a real-world demonstration.

==Tools==
===Zembly===
[http://zembly.com/ Zembly] is a tool for creating widgets for some of the big social sites. Could help get hospitality-specific apps into them.

===Overlay Weaver===
[http://overlayweaver.sourceforge.net/ Overlay Weaver] is a tool for designing and testing overlay networks like [http://en.wikipedia.org/wiki/Kademlia Kademlia], which are used in many P2P systems.

[[Category:P2P Hospitality]]

P2P Hospitality initiatives and proposals

2009-10-19T19:26:10Z

Matrixpoint: /* 3M's Brainstorming notes */

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, such as this [[P2P Resources | P2P resources page]]. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. (A Java-based solution is under development. More info later.)

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A Decentralized networks discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

P2P Resources

2009-10-19T19:23:49Z

Matrixpoint:

==General information==
===The Foundation for P2P Alternatives===
[http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki]

[http://blog.p2pfoundation.net/ P2P Foundation blog]

[http://p2pfoundation.ning.com/ P2P Foundation ning social website]

The P2P foundation is probably the best resource for information about the Peer-to-Peer movement. The wiki has articles covering many subjects such as Governance, Business, Design, Manufacturing, Production, Energy, Money, Politics, Spirituality, Technology.

===WatchUsNow film===
The [http://watch.usnowfilm.com/subtitled WatchUsNow film] is a documentary examining the impact of the social web on society. Couchsurfing is covered, along with P2P-related examples.

===Life Inc.===
[http://vimeo.com/4655092 Life Inc. The Movie] is a short video version of the best selling book by Douglass Rushkoff. Great insights into the value of decentralization to our society.

===Daemon: Bot-mediated reality talk===
Daniel Suarez, author of the best selling techno-thriller Daemon gave an interesting [http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality talk] at the Long Now Foundation. It makes us take decentralization and privacy seriously.

==Hardware/Software platforms==
===Ning===
[http://www.ning.com/ Ning] is a ready-to-go professionally run (not open-source) site that provides the tools to quickly set up a fully-functional customizable social web site. It might be a good interim solution for communities who just want a quick alternative to the big sites.

===Noserub===
[http://noserub.com Noserub] is an open-source social web site that can be set up on a single PC (configured as a server) or on a server. It aggregates user activity from any other Noserub sites or popular big social web sites that the user has an account on. Besides being convenient as an aggregator, it has a big privacy advantage in that the user has potentially much more control over his data (profile, messages, friend connections).

A demonstration (and practically useful) implementation of Noserub is [http://identoo.com Identoo]. You can open an account there to test it's features.

A drawback is that Noserub doesn't yet have built-in groups, but they are in the works for future release. Noserub only has a handful of part-time developers, so progress can be slow.

===RetroShare===
[http://retroshare.sourceforge.net/ RetroShare] is an open-source P2P network with a strong emphasis on privacy. It's actually closer to F2F (Friend-to-Friend), meant to be very private. Development is more active and it is more socially oriented than the P2P [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] file sharing network.

===Open-source file-sharing===

We are not really interested in file sharing ''per se'', but the file sharing community has led the way technically with P2P and privacy solutions, so we may be able to borrow some techniques. Here is a list of noteworthy examples:

*[http://oneswarm.cs.washington.edu/ OneSwarm]
*[http://anomos.info/ Anomos]
*[http://en.wikipedia.org/wiki/Anonet Anonet]
*[http://en.wikipedia.org/wiki/ANts_P2P ANts]
*[http://gnunet.org/ Gnunet]
*[http://en.wikipedia.org/wiki/I2P I2P]
*[http://www.lifesocial.org/ Lifesocial]
*[http://allmydata.org/trac/tahoe Tahoe]

===Wuala===
[http://www.wuala.com/ Wuala] is not open-source, but has an advanced and professional-quality partly-P2P file storage system. It has some nice privacy and social features.

===Portable apps===
[http://portableapps.com/ Portable Apps] is an open-source solution which allows a user to take not only their data, but their applications with them when they travel on a USB stick. This has implications for P2P hospitality. Besides the general convenience for travelers, our proposed P2P trust network would probably have a private identity key. You could take not only the key, but the P2P trust network software itself on the road with you, making it easier to use from any PC.

[http://www.lupopensuite.com/ Lupo PenSuite] is another portability solution which has a long list of [http://www.lupopensuite.com/a-internet.htm portable apps].

===Popeye adaptive grid network===
[http://www.ist-popeye.eu/ Popeye] is an open-source product of academia supported by the EU. Over two years they developed a working demo. Computers in physical proximity automatically form a network which adapts to nodes moving, entering and leaving, while providing file sharing, messaging, voting, etc., services useful to a working group. Includes a video of a real-world demonstration.

==Tools==
===Zembly===
[http://zembly.com/ Zembly] is a tool for creating widgets for some of the big social sites. Could help get hospitality-specific apps into them.

===Overlay Weaver===
[http://overlayweaver.sourceforge.net/ Overlay Weaver] is a tool for designing and testing overlay networks like [http://en.wikipedia.org/wiki/Kademlia Kademlia], which are used in many P2P systems.

P2P Resources

2009-10-19T19:14:09Z

Matrixpoint:

==Information==
===The Foundation for P2P Alternatives===
[http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki]

[http://blog.p2pfoundation.net/ P2P Foundation blog]

[http://p2pfoundation.ning.com/ P2P Foundation ning social website]

The P2P foundation is probably the best resource for information about the Peer-to-Peer movement. The wiki has articles covering many subjects such as Governance, Business, Design, Manufacturing, Production, Energy, Money, Politics, Spirituality, Technology.

===WatchUsNow film===
The [http://watch.usnowfilm.com/subtitled WatchUsNow film] is a documentary examining the impact of the social web on society. Couchsurfing is covered, along with P2P-related examples.

===Life Inc.===
[http://vimeo.com/4655092 Life Inc. The Movie] is a short video version of the best selling book by Douglass Rushkoff. Great insights into the value of decentralization to our society.

===Daemon: Bot-mediated reality talk===
Daniel Suarez, author of the best selling techno-thriller Daemon gave an interesting [http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality talk] at the Long Now Foundation. It makes us take decentralization and privacy seriously.

==Hardware/Software platforms==

===Ning===
[http://www.ning.com/ Ning] is a ready-to-go professionally run (not open-source) site that provides the tools to quickly set up a fully-functional customizable social web site. It might be a good interim solution for communities who just want a quick alternative to the big sites.

===Noserub===
[http://noserub.com Noserub] is an open-source social web site that can be set up on a single PC (configured as a server) or on a server. It aggregates user activity from any other Noserub sites or popular big social web sites that the user has an account on. Besides being convenient as an aggregator, it has a big privacy advantage in that the user has potentially much more control over his data (profile, messages, friend connections).

A demonstration (and practically useful) implementation of Noserub is [http://identoo.com Identoo]. You can open an account there to test it's features.

A drawback is that Noserub doesn't yet have built-in groups, but they are in the works for future release. Noserub only has a handful of part-time developers, so progress can be slow.

===RetroShare===
[http://retroshare.sourceforge.net/ RetroShare] is an open-source P2P network with a strong emphasis on privacy. It's actually closer to F2F (Friend-to-Friend), meant to be very private. Development is more active and it is more socially oriented than the P2P [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] file sharing network.

===Open-source file-sharing===

We are not really interested in file sharing per se, but the file sharing community has led the way technically with P2P and privacy solutions, so we be able to borrow some techniques. Here is a list of noteworthy examples:

*[http://oneswarm.cs.washington.edu/ OneSwarm]
*[http://anomos.info/ Anomos]
*[http://en.wikipedia.org/wiki/Anonet Anonet]
*[http://en.wikipedia.org/wiki/ANts_P2P ANts]
*[http://gnunet.org/ Gnunet]
*[http://en.wikipedia.org/wiki/I2P I2P]
*[http://www.lifesocial.org/ Lifesocial]
*[http://allmydata.org/trac/tahoe Tahoe]

===Wuala===
[http://www.wuala.com/ Wuala] is not open-source, but has an advanced and professional-quality partly-P2P file storage system. It has some nice privacy and social features.

===Portable apps===
[http://portableapps.com/ Portable Apps] is an open-source solution which allows a user to take not only their data, but their applications with them when they travel on a USB stick. This has implications for P2P hospitality. Besides the general convenience for travelers, our proposed P2P trust network would probably have a private identity key. You could take not only the key, but the P2P trust network software itself on the road with you, making it easier to use from any PC.

[http://www.lupopensuite.com/ Lupo PenSuite] is another portability solution which has a long list of [http://www.lupopensuite.com/a-internet.htm portable apps].

===Popeye adaptive grid network===
[http://www.ist-popeye.eu/ Popeye] is an open-source product of academia supported by the EU. Over two years they developed a working demo. Computers in physical proximity automatically form a network which adapts to nodes moving, entering and leaving, while providing file sharing, messaging, voting, etc., services useful to a working group. Includes a video of a real-world demonstration.

P2P Resources

2009-10-19T18:59:05Z

Matrixpoint:

==Information==
===The Foundation for P2P Alternatives===
[http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki]

[http://blog.p2pfoundation.net/ P2P Foundation blog]

[http://p2pfoundation.ning.com/ P2P Foundation ning social website]

The P2P foundation is probably the best resource for information about the Peer-to-Peer movement. The wiki has articles covering many subjects such as Governance, Business, Design, Manufacturing, Production, Energy, Money, Politics, Spirituality, Technology.

===WatchUsNow film===
The [http://watch.usnowfilm.com/subtitled WatchUsNow film] is a documentary examining the impact of the social web on society. Couchsurfing is covered, along with P2P-related examples.

===Life Inc.===
[http://vimeo.com/4655092 Life Inc. The Movie] is a short video version of the best selling book by Douglass Rushkoff. Great insights into the value of decentralization to our society.

==Hardware/Software platforms==

===Ning===
[http://www.ning.com/ Ning] is a ready-to-go professionally run (not open-source) site that provides the tools to quickly set up a fully-functional customizable social web site. It might be a good interim solution for communities who just want a quick alternative to the big sites.

===Noserub===
[http://noserub.com Noserub] is an open-source social web site that can be set up on a single PC (configured as a server) or on a server. It aggregates user activity from any other Noserub sites or popular big social web sites that the user has an account on. Besides being convenient as an aggregator, it has a big privacy advantage in that the user has potentially much more control over his data (profile, messages, friend connections).

A demonstration (and practically useful) implementation of Noserub is [http://identoo.com Identoo]. You can open an account there to test it's features.

A drawback is that Noserub doesn't yet have built-in groups, but they are in the works for future release. Noserub only has a handful of part-time developers, so progress can be slow.

===RetroShare===
[http://retroshare.sourceforge.net/ RetroShare] is an open-source P2P network with a strong emphasis on privacy. It's actually closer to F2F (Friend-to-Friend), meant to be very private. Development is more active and it is more socially oriented than the P2P [http://www.emule-project.net/home/perl/general.cgi?l=1 eMule] file sharing network.

===Open-source file-sharing===

We are not really interested in file sharing per se, but the file sharing community has led the way technically with P2P and privacy solutions, so we be able to borrow some techniques. Here is a list of noteworthy examples:

*[http://oneswarm.cs.washington.edu/ OneSwarm]
*[http://anomos.info/ Anomos]
*[http://en.wikipedia.org/wiki/Anonet Anonet]
*[http://en.wikipedia.org/wiki/ANts_P2P ANts]
*[http://gnunet.org/ Gnunet]
*[http://en.wikipedia.org/wiki/I2P I2P]

===Wuala===
[http://www.wuala.com/ Wuala] is not open-source, but has an advanced and professional-quality partly-P2P file storage system. It has some nice privacy and social features.

===Portable apps===
[http://portableapps.com/ Portable Apps] is an open-source solution which allows a user to take not only their data, but their applications with them when they travel on a USB stick. This has implications for P2P hospitality. Besides the general convenience for travelers, our proposed P2P trust network would probably have a private identity key. You could take not only the key, but the P2P trust network software itself on the road with you, making it easier to use from any PC.

[http://www.lupopensuite.com/ Lupo PenSuite] is another portability solution which has a long list of [http://www.lupopensuite.com/a-internet.htm portable apps].

P2P Resources

2009-10-19T18:26:02Z

Matrixpoint:

P2P Resources

2009-10-19T17:53:55Z

Matrixpoint: Created page with '==Information== ===The Foundation for P2P Alternatives=== [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P Foundation wiki] [http://blog.p2pfoundation.net/ P2P …'

P2P Hospitality initiatives and proposals

2009-10-19T16:55:56Z

Matrixpoint: /* 3M's Brainstorming notes */

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, including links to many [[P2P Resources | resources]]. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. (A Java-based solution is under development. More info later.)

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A Decentralized networks discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

Why decentralization in hospex?

2009-10-18T05:01:14Z

Matrixpoint:

This is a philosophical overview related to P2P hospitality.

Ongoing [[P2P Hospitality initiatives and proposals]] are elsewhere.

==The case for decentralization==

Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous abundance and richness of the natural world is a case study in the benefits of a web of interconnected sub-ecosystems, each of which is quasi-independent.

Human society is in the midst of a crisis which, on one level, is the consequence of centralized power and wealth. Wherever concentrated power exists, it attracts parasites and predators who feed or prey upon those they dominate. Even well-intended people can be seduced and corrupted by power, and so measures to counteract its corrupting influence are always necessary.

The best defense against concentrated power is decentralization. To whatever extent a centralized social structure is deemed necessary, checking and balancing mechanisms should always be incorporated. Since no system is perfect for all times and circumstances, the ultimate success of a society depends on the willingness of its members to constantly monitor and upgrade their system as needed.

When a few control the many, everyone loses in the long run. Individual creativity and initiative are stifled and replaced by a robotic uniformity and conformity. Bottlenecks occur as information attempts to transit layers of bureaucracy and chains of command. Serial processing replaces parallel processing, reducing productivity and effectiveness. The whole system becomes monolithic, sluggish, and vulnerable.

What's good for the ruling elite becomes what's good for the ruled. A class of bureaucrats and sycophants arises which must demonstrate loyalty to the rulers or be demoted or expelled. The mission of the organization becomes subverted in favor of perpetuating the positions of power and wealth of a privileged few. Secrecy and unaccountability prevail over integrity. ''Honor dies where self-interest lies''.

The problems associated with centralized power in the world are more visible every day, in virtually every sector, but especially finance. There is a movement afoot that amounts to a world-wide paradigm shift away from centralized power: the Peer-to-Peer or P2P movement. The best resource for learning about it is probably the [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives The Foundation for P2P Alternatives]. Some believe that a transformation from a pyramidal social structure to a holographic structure is the best hope for humanity to enter a new Renaissance. ''Unity in diversity; transparency with respect for privacy.'' Let's include the hospex movement in this paradigm shift.

==Holographic hospitality==

Hospitality is naturally decentralized. It can and does happen spontaneously between people all over our planet. The fundamental principle involved is sharing; typically shelter, food, information and guidance for strangers or travelers. In a broader sense, hospitality includes any gesture of kindness and welcome, when offered without expectation of immediate reciprocation other than perhaps simple appreciation and respect. If there is any movement which should be protected from predators and parasites, it is the hospex movement.

In the context of hospex, decentralization would manifest as many loosely-connected but autonomous communities. There is already a trend in this direction with a handful of traditional web-sites now available ([[:cs:|CS]], [http://hospitalityclub.org HC], [http://bewelcome.org BW], [http://belodged.com BL], [http://servas.org Servas], [http://www.internations.org InterNations], etc.). Further decentralization might be encouraged if technological barriers were reduced and if universal standards, protocols and tools were established for interaction between hospex networks.

One beneficial innovation would be a distributed (P2P) global trust/reputation network. The nodes of such a network would be individuals or sub-networks, both searchable using descriptive tags. It should be free and open-source and operate on distributed personal computers, much the way the bittorrent file-sharing system works (but without server-based trackers). Its only role would be to provide global interconnectivity between diverse hospex entities. Everything else is left to the discretion of the sub-networks. No one could own or control it.

Sub-networks might include geographically-localized communities or special-interest peer-groups. The hardware/software platforms used by such sub-networks could be varied: anything available and adaptable to hospex needs. One promising platform is [http://noserub.com Noserub], which can be run by an individual on a PC, by a small community on a distributed network of PC's (in principle) or on a server. It has the advantage of allowing an individual or group to maintain control over their personal data while still participating in multiple Noserub communities or any of the big social websites like [http://facebook.com Facebook], [http://myspace.com Myspace], [http://orkut.com Orkut], etc.

Some communities might focus on humanitarian projects. Others might focus on travel and/or cultural exchange, or perhaps on shared recreational, religious, lifestyle or professional interests. Some may have high standards of integrity and trust, while others emphasize privacy or safety. Governance could range from authoritarian to democratic to anarchist, but no one person or group could dominate all others. There would be something for everyone and the entire hospex movement would be enriched. Trust relations between communities would naturally evolve through diplomacy, exchanges and cooperative endeavors.

[[Category:P2P Hospitality]]
[[Category:Philosophy]]

Why decentralization in hospex?

2009-10-17T15:59:06Z

Matrixpoint: /* Holographic hospitality */

Why decentralization in hospex?

2009-10-17T12:18:16Z

Matrixpoint: /* Holographic hospex */

This is a philosophical overview related to P2P hospitality.

Ongoing [[P2P Hospitality initiatives and proposals]] are elsewhere.

==The case for decentralization==

Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous abundance and richness of the natural world is a case study in the benefits of a web of interconnected sub-ecosystems, each of which is quasi-independent.

Human society is in the midst of a crisis which, on one level, is the consequence of centralized power and wealth. Wherever concentrated power exists, it attracts parasites and predators who feed or prey upon those they dominate. Even well-intended people can be seduced and corrupted by power, and so measures to counteract its corrupting influence are always necessary.

The best defense against concentrated power is decentralization. To whatever extent a centralized social structure is deemed necessary, checking and balancing mechanisms should always be incorporated. Since no system is perfect for all times and circumstances, the ultimate success of a society depends on the willingness of its members to constantly monitor and upgrade their system as needed.

When a few control the many, everyone loses in the long run. Individual creativity and initiative are stifled and replaced by a robotic uniformity and conformity. Bottlenecks occur as information attempts to transit layers of bureaucracy and chains of command. Serial processing replaces parallel processing, reducing productivity and effectiveness. The whole system becomes monolithic, sluggish, and vulnerable.

What's good for the ruling elite becomes what's good for the ruled. A class of bureaucrats and sycophants arises which must demonstrate loyalty to the rulers or be demoted or expelled. The mission of the organization becomes subverted in favor of perpetuating the positions of power and wealth of a privileged few. Secrecy and unaccountability prevail over integrity. ''Honor dies where self-interest lies''.

The problems associated with centralized power in the world are more visible every day, in virtually every sector, but especially finance. There is a movement afoot that amounts to a world-wide paradigm shift away from centralized power: the Peer-to-Peer or P2P movement. The best resource for learning about it is probably the [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives The Foundation for P2P Alternatives]. Some believe that a transformation from a pyramidal social structure to a holographic structure is the best hope for humanity to enter a new Renaissance. ''Unity in diversity; transparency with respect for privacy.'' Let's include the hospex movement in this paradigm shift.

==Holographic hospex==

Hospex (hospitality exchange) is naturally decentralized. It can and does happen spontaneously between people all over our planet. The fundamental principle involved is sharing; typically shelter, food, information and guidance for strangers or travelers. In a broader sense, hospitality includes any gesture of kindness and welcome, when offered without expectation of immediate reciprocation other than perhaps simple appreciation and respect. If there is any movement which should be protected from predators and parasites, it is the hospex movement.

In the context of hospex, decentralization would manifest as many loosely-connected but autonomous communities. There is already a trend in this direction with a handful of traditional web-sites now available ([[:cs:|CS]], [http://hospitalityclub.org HC], [http://bewelcome.org BW], [http://belodged.com BL], [http://servas.org Servas], [http://www.internations.org InterNations], etc.). Further decentralization might be encouraged if technological barriers were reduced and if universal standards, protocols and tools were established for interaction between hospex networks.

One beneficial innovation would be a distributed (P2P) global trust/reputation network. The nodes of such a network would be individuals or sub-networks, both searchable using descriptive tags. It should be free and open-source and operate on distributed personal computers, much the way the bittorrent file-sharing system works (but without server-based trackers). Its only role would be to provide global interconnectivity between diverse hospex entities. Everything else is left to the discretion of the sub-networks. No one could own or control it.

Sub-networks might include geographically-localized communities or special-interest peer-groups. The hardware/software platforms used by such sub-networks could be varied: anything available and adaptable to hospex needs. One promising platform is [http://noserub.com Noserub], which can be run by an individual on a PC, by a small community on a distributed network of PC's (in principle) or on a server. It has the advantage of allowing an individual or group to maintain control over their personal data while still participating in multiple Noserub communities or any of the big social websites like [http://facebook.com Facebook], [http://myspace.com Myspace], [http://orkut.com Orkut], etc.

Some communities might focus on humanitarian projects. Others might focus on travel and/or cultural exchange, or perhaps on shared recreational, religious, lifestyle or professional interests. Some may have high standards of integrity and trust, while others emphasize privacy or safety. Governance could range from authoritarian to democratic to anarchist, but no one person or group could dominate all others. There would be something for everyone and the entire hospex movement would be enriched. Trust relations between communities would naturally evolve through diplomacy, exchanges and cooperative endeavors.

[[Category:P2P Hospitality]]

Why decentralization in hospex?

2009-10-17T11:53:42Z

Matrixpoint: /* Holographic hospex */

This is a philosophical overview related to P2P hospitality.

Ongoing [[P2P Hospitality initiatives and proposals]] are elsewhere.

==The case for decentralization==

Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous abundance and richness of the natural world is a case study in the benefits of a web of interconnected sub-ecosystems, each of which is quasi-independent.

Human society is in the midst of a crisis which, on one level, is the consequence of centralized power and wealth. Wherever concentrated power exists, it attracts parasites and predators who feed or prey upon those they dominate. Even well-intended people can be seduced and corrupted by power, and so measures to counteract its corrupting influence are always necessary.

The best defense against concentrated power is decentralization. To whatever extent a centralized social structure is deemed necessary, checking and balancing mechanisms should always be incorporated. Since no system is perfect for all times and circumstances, the ultimate success of a society depends on the willingness of its members to constantly monitor and upgrade their system as needed.

When a few control the many, everyone loses in the long run. Individual creativity and initiative are stifled and replaced by a robotic uniformity and conformity. Bottlenecks occur as information attempts to transit layers of bureaucracy and chains of command. Serial processing replaces parallel processing, reducing productivity and effectiveness. The whole system becomes monolithic, sluggish, and vulnerable.

What's good for the ruling elite becomes what's good for the ruled. A class of bureaucrats and sycophants arises which must demonstrate loyalty to the rulers or be demoted or expelled. The mission of the organization becomes subverted in favor of perpetuating the positions of power and wealth of a privileged few. Secrecy and unaccountability prevail over integrity. ''Honor dies where self-interest lies''.

The problems associated with centralized power in the world are more visible every day, in virtually every sector, but especially finance. There is a movement afoot that amounts to a world-wide paradigm shift away from centralized power: the Peer-to-Peer or P2P movement. The best resource for learning about it is probably the [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives The Foundation for P2P Alternatives]. Some believe that a transformation from a pyramidal social structure to a holographic structure is the best hope for humanity to enter a new Renaissance. ''Unity in diversity; transparency with respect for privacy.'' Let's include the hospex movement in this paradigm shift.

==Holographic hospex==

Hospex (hospitality exchange) is naturally decentralized. It can and does happen spontaneously between people all over our planet. The fundamental principle involved is sharing; typically shelter, food, information and guidance for strangers or travelers. In a broader sense, hospitality includes any gesture of kindness and welcome, when offered without expectation of immediate reciprocation other than perhaps simple appreciation and respect. If there is any movement which should be protected from predators and parasites, it is the hospex movement.

In the context of hospex, decentralization would manifest as many loosely-connected but autonomous communities. There is already a trend in this direction with a handful of traditional web-sites now available ([[:cs:|CS]], [http://hospitalityclub.org HC], [http://bewelcome.org BW], [http://belodged.com BL], [http://servas.org Servas], etc.). Further decentralization might be encouraged if technological barriers were reduced and if universal standards, protocols and tools were established for interaction between hospex networks.

One beneficial innovation would be a distributed (P2P) global trust/reputation network. The nodes of such a network would be individuals or sub-networks, both searchable using descriptive tags. It should be free and open-source and operate on distributed personal computers, much the way the bittorrent file-sharing system works (but without server-based trackers). Its only role would be to provide global interconnectivity between diverse hospex entities. Everything else is left to the discretion of the sub-networks. No one could own or control it.

Sub-networks might include geographically-localized communities or special-interest peer-groups. The hardware/software platforms used by such sub-networks could be varied: anything available and adaptable to hospex needs. One promising platform is [http://noserub.com Noserub], which can be run by an individual on a PC, by a small community on a distributed network of PC's (in principle) or on a server. It has the advantage of allowing an individual or group to maintain control over their personal data while still participating in multiple Noserub communities or any of the big social websites like [http://facebook.com Facebook], [http://myspace.com Myspace], [http://orkut.com Orkut], etc.

Some communities might focus on humanitarian projects. Others might focus on travel and/or cultural exchange, or perhaps on shared recreational, religious, lifestyle or professional interests. Some may have high standards of integrity and trust, while others emphasize privacy or safety. Governance could range from authoritarian to democratic to anarchist, but no one person or group could dominate all others. There would be something for everyone and the entire hospex movement would be enriched. Trust relations between communities would naturally evolve through diplomacy, exchanges and cooperative endeavors.

[[Category:P2P Hospitality]]

Why decentralization in hospex?

2009-10-17T11:50:53Z

Matrixpoint: /* The case for decentralization */

This is a philosophical overview related to P2P hospitality.

Ongoing [[P2P Hospitality initiatives and proposals]] are elsewhere.

==The case for decentralization==

Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous abundance and richness of the natural world is a case study in the benefits of a web of interconnected sub-ecosystems, each of which is quasi-independent.

Human society is in the midst of a crisis which, on one level, is the consequence of centralized power and wealth. Wherever concentrated power exists, it attracts parasites and predators who feed or prey upon those they dominate. Even well-intended people can be seduced and corrupted by power, and so measures to counteract its corrupting influence are always necessary.

The best defense against concentrated power is decentralization. To whatever extent a centralized social structure is deemed necessary, checking and balancing mechanisms should always be incorporated. Since no system is perfect for all times and circumstances, the ultimate success of a society depends on the willingness of its members to constantly monitor and upgrade their system as needed.

When a few control the many, everyone loses in the long run. Individual creativity and initiative are stifled and replaced by a robotic uniformity and conformity. Bottlenecks occur as information attempts to transit layers of bureaucracy and chains of command. Serial processing replaces parallel processing, reducing productivity and effectiveness. The whole system becomes monolithic, sluggish, and vulnerable.

What's good for the ruling elite becomes what's good for the ruled. A class of bureaucrats and sycophants arises which must demonstrate loyalty to the rulers or be demoted or expelled. The mission of the organization becomes subverted in favor of perpetuating the positions of power and wealth of a privileged few. Secrecy and unaccountability prevail over integrity. ''Honor dies where self-interest lies''.

The problems associated with centralized power in the world are more visible every day, in virtually every sector, but especially finance. There is a movement afoot that amounts to a world-wide paradigm shift away from centralized power: the Peer-to-Peer or P2P movement. The best resource for learning about it is probably the [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives The Foundation for P2P Alternatives]. Some believe that a transformation from a pyramidal social structure to a holographic structure is the best hope for humanity to enter a new Renaissance. ''Unity in diversity; transparency with respect for privacy.'' Let's include the hospex movement in this paradigm shift.

==Holographic hospex==

Hospex (hospitality exchange) is naturally decentralized. It can and does happen spontaneously between people all over our planet. The fundamental principle involved is sharing; typically shelter, food, information and guidance for strangers or travelers. In a broader sense, hospitality includes any gesture of kindness and welcome, when offered without expectation of immediate reciprocation other than perhaps simple appreciation and respect. If there is any movement which should be protected from predators and parasites, it is the hospex movement.

In the context of hospex, decentralization would manifest as many loosely-connected but autonomous communities. There is already a trend in this direction with a handful of traditional web-sites now available ([[:cs:|CS]], [http://hospitalityclub.org HC], [http://bewelcome.org BW], [http://belodged.com BL], [http://servas.org Servas], etc.). Further decentralization might be encouraged if technological barriers were reduced and if universal standards, protocols and tools were established for interaction between hospex networks.

One beneficial innovation would be a distributed (P2P) global trust/reputation network. The nodes of such a network would be individuals or sub-networks, both searchable using descriptive tags. It should be free and open-source and operate on distributed personal computers, much the way the bittorrent file-sharing system works (but without server-based trackers). Its only role is to provide global interconnectivity between diverse hospex entities. Everything else is left to the discretion of the sub-networks. No one could own or control it.

Sub-networks might include geographically-localized communities or special-interest peer-groups. The hardware/software platforms used by such sub-networks could be varied: anything available and adaptable to hospex needs. One promising platform is [http://noserub.com Noserub], which can be run by an individual on a PC, by a small community on a distributed network of PC's (in principle) or on a server. It has the advantage of allowing an individual or group to maintain control over their personal data while still participating in multiple Noserub communities or any of the big social websites like [http://facebook.com Facebook], [http://myspace.com Myspace], [http://orkut.com Orkut], etc.

Some communities might focus on humanitarian projects. Others might focus on travel and/or cultural exchange, or perhaps on shared recreational, religious, lifestyle or professional interests. Some may have high standards of integrity and trust, while others emphasize privacy or safety. Governance could range from authoritarian to democratic to anarchist, but no one person or group could dominate all others. There would be something for everyone and the entire hospex movement would be enriched. Trust relations between communities would naturally evolve through diplomacy, exchanges and cooperative endeavors.

[[Category:P2P Hospitality]]

P2P Hospitality initiatives and proposals

2009-10-17T11:47:07Z

Matrixpoint: /* A Decentralized network discussion by Lemon-head */

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, including links to many resources. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. (A Java-based solution is under development. More info later.)

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A Decentralized networks discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

P2P Hospitality initiatives and proposals

2009-10-17T11:46:46Z

Matrixpoint: /* A decentralized network discussion by Lemon-head */

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, including links to many resources. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. (A Java-based solution is under development. More info later.)

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A Decentralized network discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

Decentralized networks

2009-10-17T11:44:41Z

Matrixpoint:

For a long time the idea has been floating around to have independent and '''decentralized networks''' as an alternative to the existing centralized (= one user database, one management) [[hospitality]] networks.

The idea is interesting, but has some difficult aspects, that can be discussed on this page.

== Why? ==

Is decentralized always better?

Always? Probably not. But that should not stop anyone from exploring!

The great benefit of decentralized networks is that they allow to experiment with different technology, different styles of moderation, different safety and trust features, different search features, different looks, different peer groups.

== How this can work ==
A lot can be said about decentralized networks, but in the context of [[hospitality exchange]] the most important is user profiles, (location-based) member search, messages between members, and [[trust]] / [[friend]] connections. All of this has to work across different networks, otherwise it won't be really useful.

The biggest challenges here are [[privacy]] and proof of [[identity]]: How can one restrict the visibility of information that is shared across different networks? And how can I prove that I am the owner of profile A on network X, when interacting with members form network Y?

=== User accounts / profiles ===
The idea would mean that there is not one big network where you create a user account, but instead you would choose one or more networks where you want to create an account and have the information you define stored in the database.

Problems:
* Multi-accounts: Duplicate search results, and redundant information to update in different places.
* Agony of choice: How to choose my favorite network?

Solutions:
* Tools for import, export and profile migration
* Auto-update a profile on site X with information from site Y.

=== Searching member profiles ===
To make member search useful, it has to be cross-network. This means, a search request either has to request information from all connected networks, or you need some kind of search engine that crawls member profiles on different networks and caches the information.

Problems:
* Privacy: Information that is shared between an arbitrary number of networks is practically public information.

Solutions:

=== Messages from one user to another ===
You go to someone's profile on network X, click "send message", type the message, submit. You leave a link to your own profile on network Y.

Problems:
* You need to type in the link to your own profile manually, which is inconvenient, and you can make typos.
* You can type in a fake link to someone else's profile.

Solutions:
* OpenID? Does that allow to identify you as a member of a different network?

=== Trust/Friend links between members ===
Just like the references or friend links in couchsurfing, you could create a trust link from profile A in network X to profile B in network Y.

This can only work if there is a way to prove that your friend link does in fact come from profile A in network X, and not from somewhere else. This is the same problem as with messages.

=== Profile data visibility constraints ===
In traditional networks it is possible to show some profile information "only to my friends", or have some other constraints. How can I control that if the friends' profiles are on separate networks?

=== [[Trust]] links between networks ===
Just like there can be a trust network of people, there can also be a trust network of networks..

== Examples ==

* Crash at Mine (?)
* Noserub
*: Q: How does Noserub solve the above "problems" ?

[[Category:P2P Hospitality]]

Why decentralization in hospex?

2009-10-17T11:41:49Z

Matrixpoint:

This is a philosophical overview related to P2P hospitality.

Ongoing [[P2P Hospitality initiatives and proposals]] are elsewhere.

==The case for decentralization==

Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous abundance and richness of the natural world is a case study in the benefits of a web of interconnected sub-ecosystems, each of which is quasi-independent.

Human society is in the midst of a crisis which, on one level, is the consequence of centralized power and wealth. Wherever concentrated power exists, it attracts parasites and predators who feed or prey upon those they dominate. Even well-intended people can be seduced and corrupted by power, and so measures to counteract its corrupting influence are always necessary.

The best defense against concentrated power is decentralization. To whatever extent a centralized social structure is deemed necessary, checking and balancing mechanisms should always be incorporated. Since no system is perfect for all times and circumstances, the ultimate success of a society depends on the willingness of its members to constantly monitor and upgrade their system as needed.

When a few control the many, everyone loses in the long run. Individual creativity and initiative are stifled and replaced by a robotic uniformity and conformity. Bottlenecks occur as information attempts to transit layers of bureaucracy and chains of command. Serial processing replaces parallel processing, reducing productivity and effectiveness. The whole system becomes monolithic, sluggish, and vulnerable.

What's good for the ruling elite becomes what's good for the ruled. A class of bureaucrats and sycophants arises which must demonstrate loyalty to the rulers or be demoted or expelled. The mission of the organization becomes subverted in favor of perpetuating the positions of power and wealth of a privileged few. Secrecy and unaccountability prevail over integrity. ''Honor dies where self-interest lies''.

The problems associated with centralized power in the world are more visible every day, in virtually every sector, but especially finance. There is a movement afoot that amounts to a world-wide paradigm shift away from centralized power: the Peer-to-Peer or P2P movement. The best resource for learning about it is probably the [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P foundation]. Some believe that a transformation from a pyramidal social structure to a holographic structure is the best hope for humanity to enter a new Renaissance. ''Unity in diversity; transparency with respect for privacy.'' Let's include the hospex movement in this paradigm shift.

==Holographic hospex==

Hospex (hospitality exchange) is naturally decentralized. It can and does happen spontaneously between people all over our planet. The fundamental principle involved is sharing; typically shelter, food, information and guidance for strangers or travelers. In a broader sense, hospitality includes any gesture of kindness and welcome, when offered without expectation of immediate reciprocation other than perhaps simple appreciation and respect. If there is any movement which should be protected from predators and parasites, it is the hospex movement.

In the context of hospex, decentralization would manifest as many loosely-connected but autonomous communities. There is already a trend in this direction with a handful of traditional web-sites now available ([[:cs:|CS]], [http://hospitalityclub.org HC], [http://bewelcome.org BW], [http://belodged.com BL], [http://servas.org Servas], etc.). Further decentralization might be encouraged if technological barriers were reduced and if universal standards, protocols and tools were established for interaction between hospex networks.

One beneficial innovation would be a distributed (P2P) global trust/reputation network. The nodes of such a network would be individuals or sub-networks, both searchable using descriptive tags. It should be free and open-source and operate on distributed personal computers, much the way the bittorrent file-sharing system works (but without server-based trackers). Its only role is to provide global interconnectivity between diverse hospex entities. Everything else is left to the discretion of the sub-networks. No one could own or control it.

Sub-networks might include geographically-localized communities or special-interest peer-groups. The hardware/software platforms used by such sub-networks could be varied: anything available and adaptable to hospex needs. One promising platform is [http://noserub.com Noserub], which can be run by an individual on a PC, by a small community on a distributed network of PC's (in principle) or on a server. It has the advantage of allowing an individual or group to maintain control over their personal data while still participating in multiple Noserub communities or any of the big social websites like [http://facebook.com Facebook], [http://myspace.com Myspace], [http://orkut.com Orkut], etc.

Some communities might focus on humanitarian projects. Others might focus on travel and/or cultural exchange, or perhaps on shared recreational, religious, lifestyle or professional interests. Some may have high standards of integrity and trust, while others emphasize privacy or safety. Governance could range from authoritarian to democratic to anarchist, but no one person or group could dominate all others. There would be something for everyone and the entire hospex movement would be enriched. Trust relations between communities would naturally evolve through diplomacy, exchanges and cooperative endeavors.

[[Category:P2P Hospitality]]

Why decentralization in hospex?

2009-10-17T11:32:21Z

Matrixpoint: Created page with '==The case for decentralization== Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous…'

==The case for decentralization==

Decentralization encourages diversity, resiliency, and adaptability; it discourages uniformity, fragility, and unresponsiveness. The tremendous abundance and richness of the natural world is a case study in the benefits of a web of interconnected sub-ecosystems, each of which is quasi-independent.

Human society is in the midst of a crisis which, on one level, is the consequence of centralized power and wealth. Wherever concentrated power exists, it attracts parasites and predators who feed or prey upon those they dominate. Even well-intended people can be seduced and corrupted by power, and so measures to counteract its corrupting influence are always necessary.

The best defense against concentrated power is decentralization. To whatever extent a centralized social structure is deemed necessary, checking and balancing mechanisms should always be incorporated. Since no system is perfect for all times and circumstances, the ultimate success of a society depends on the willingness of its members to constantly monitor and upgrade their system as needed.

When a few control the many, everyone loses in the long run. Individual creativity and initiative are stifled and replaced by a robotic uniformity and conformity. Bottlenecks occur as information attempts to transit layers of bureaucracy and chains of command. Serial processing replaces parallel processing, reducing productivity and effectiveness. The whole system becomes monolithic, sluggish, and vulnerable.

What's good for the ruling elite becomes what's good for the ruled. A class of bureaucrats and sycophants arises which must demonstrate loyalty to the rulers or be demoted or expelled. The mission of the organization becomes subverted in favor of perpetuating the positions of power and wealth of a privileged few. Secrecy and unaccountability prevail over integrity. ''Honor dies where self-interest lies''.

The problems associated with centralized power in the world are more visible every day, in virtually every sector, but especially finance. There is a movement afoot that amounts to a world-wide paradigm shift away from centralized power: the Peer-to-Peer or P2P movement. The best resource for learning about it is probably the [http://p2pfoundation.net/The_Foundation_for_P2P_Alternatives P2P foundation]. Some believe that a transformation from a pyramidal social structure to a holographic structure is the best hope for humanity to enter a new Renaissance. ''Unity in diversity; transparency with respect for privacy.'' Let's include the hospex movement in this paradigm shift.

==Holographic hospex==

Hospex (hospitality exchange) is naturally decentralized. It can and does happen spontaneously between people all over our planet. The fundamental principle involved is sharing; typically shelter, food, information and guidance for strangers or travelers. In a broader sense, hospitality includes any gesture of kindness and welcome, when offered without expectation of immediate reciprocation other than perhaps simple appreciation and respect. If there is any movement which should be protected from predators and parasites, it is the hospex movement.

In the context of hospex, decentralization would manifest as many loosely-connected but autonomous communities. There is already a trend in this direction with a handful of traditional web-sites now available ([[:cs:|CS]], [http://hospitalityclub.org HC], [http://bewelcome.org BW], [http://belodged.com BL], [http://servas.org Servas], etc.). Further decentralization might be encouraged if technological barriers were reduced and if universal standards, protocols and tools were established for interaction between hospex networks.

One beneficial innovation would be a distributed (P2P) global trust/reputation network. The nodes of such a network would be individuals or sub-networks, both searchable using descriptive tags. It should be free and open-source and operate on distributed personal computers, much the way the bittorrent file-sharing system works (but without server-based trackers). Its only role is to provide global interconnectivity between diverse hospex entities. Everything else is left to the discretion of the sub-networks. No one could own or control it.

Sub-networks might include geographically-localized communities or special-interest peer-groups. The hardware/software platforms used by such sub-networks could be varied: anything available and adaptable to hospex needs. One promising platform is [http://noserub.com Noserub], which can be run by an individual on a PC, by a small community on a distributed network of PC's (in principle) or on a server. It has the advantage of allowing an individual or group to maintain control over their personal data while still participating in multiple Noserub communities or any of the big social websites like [http://facebook.com Facebook], [http://myspace.com Myspace], [http://orkut.com Orkut], etc.

Some communities might focus on humanitarian projects. Others might focus on travel and/or cultural exchange, or perhaps on shared recreational, religious, lifestyle or professional interests. Some may have high standards of integrity and trust, while others emphasize privacy or safety. Governance could range from authoritarian to democratic to anarchist, but no one person or group could dominate all others. There would be something for everyone and the entire hospex movement would be enriched. Trust relations between communities would naturally evolve through diplomacy, exchanges and cooperative endeavors.

This is a philosophical overview.

Ongoing [[P2P Hospitality initiatives and proposals]].

[[Category:P2P Hospitality]]

Category:P2P Hospitality

2009-10-17T11:30:50Z

Matrixpoint: Created page with 'Category:Browse'

[[Category:Browse]]

P2P Hospitality initiatives and proposals

2009-10-17T11:29:15Z

Matrixpoint: Created page with 'This is a directory to various P2P Hospitality initiatives and proposals. There is a philosophical overview elsewhere. ==3M's Brainstorming…'

This is a directory to various P2P Hospitality initiatives and proposals. There is a [[Why decentralization in hospex? | philosophical overview]] elsewhere.

==3M's Brainstorming notes==
[[User:Midsch | Midsch]], Mahouni2000 and [[User:matrixpoint | Matrixpoint]] have been brainstorming about decentralization and privacy solutions for the past 6 months (as of 10/2009). A few more pages may appear here summarizing our explorations, including links to many resources. Our goal was to make use of existing systems, but we haven't yet found a ready-to-deploy solution. Thus, more work needs to be done. (The less, the better.) Very briefly, we see three main areas of technical activity to pursue:

* Customize [http://noserub.com Noserub] (or [http://drupal.org Drupal] or [http://buddypress.org BuddyPress] or whatever) for localized or special-interest hospex communities, packaging it so that is very easy to deploy.

* Encourage sub-communities within the big social sites like [http://facebook.com Facebook], perhaps by developing custom apps for them.

* Develop a decentralized (P2P) trust/search network. (A Java-based solution is under development. More info later.)

Some non-technical areas to explore are:

* Universal standards or guidelines for trust, safety, and privacy.

* What constitutes an identity/reputation in the virtual world?

==A P2P hospitality proposal by [[User:Robino | Robino]] on [http://sharewiki.org ShareWiki.org]==

[http://sharewiki.org/en/P2P_hospitality P2P hospitality]

==A decentralized network discussion by [[User:Lemon-Head | Lemon-head]]==

[[Decentralized networks]]

[[Category:P2P Hospitality]]

Category:CS Organization

2009-10-15T12:18:43Z

Matrixpoint: New page: Category:Browse

[[Category:Browse]]

Category:CS Organization Netherlands

2009-10-15T12:16:43Z

Matrixpoint: New page: Category:CS Organization

[[Category:CS Organization]]

CS Organisation Netherlands

2009-10-15T12:12:16Z

Matrixpoint:

{{Netherlands}}

== List of Dutch Ambassadors ==
===Country Ambassadors===
[[:cs:users/LIZZIE82ISH|Liza van Kuijk]] (Utrecht)
+ Support Dutch City ambassadors and the rest of the Netherlands CS community.
+ Member of [http://www.couchsurfing.com/group.html?gid=3581 New Member Welcome group], greeting new members in Utrecht and around.
+ Organising meetings and activities in Utrecht and assisting in others in the Netherlands.
+ Explore the other CS communities in the Netherlands and the rest of the world by surfing and going to meetings
+ Member of workinggroup for reorganising groups of the Netherlands
+ Mentor/Buddy for new ambs in the centre of the Netherlands
+ Moderator of:
+ [http://www.couchsurfing.com/group.html?gid=238 Netherlands CS group]
+ [http://www.couchsurfing.com/group.html?gid=5031 Netherlands CS organisation group]
+ [http://www.couchsurfing.com/group.html?gid=3486 Last minute couch in the Netherlands group]
+ [http://www.couchsurfing.com/group.html?gid=14572 Dutch lessons in Utrecht group]
+ [http://www.couchsurfing.com/group.html?gid=1348 Utrecht CS group]

[[:cs:users/VATO_LOCO|Henri Geerman]] (Arnhem)
+

[[:cs:users/roseathome|Rose May]] (Amsterdam)
+ Organising events (the crazier and challenging the better)
+ Social networking (drinks and dances anyone?)
+ Introduce hospitalily networks to whoever is interested
+ Really like to bring people together and see then connect with eachother
+ Like to work in teams and make things happen

===City Ambassadors===

=====[[Amsterdam]]=====
[[:cs:users/mab84|Menno]]
+

[[:cs:users/SPREEKER|Stephan Preeker]]
+

[[:cs:users/JP1978|JP1978]]
+ [http://www.couchsurfing.com/group_read.html?gid=5031&post=1334189#post1512749 post on the CSNL Group]

=====[[Rotterdam]]=====
[[:cs:users/ROSSI IN ROTTERDAM|Annemarie Rossi]]
+

[[:cs:users/raineybean|Lorraine Sanchez]]
+

[[:cs:users/GERALD_ROTTERDAM|Gerard Bosman]] (Lansingerland municipality)
+

=====[[Utrecht]]=====
[[:cs:users/KILGORETROUT|Jasper Haenen]]
+ Moderator of [http://www.couchsurfing.com/group.html?gid=1348 Utrecht CS group] and [http://www.couchsurfing.com/group.html?gid=8029 Utrecht meeting and events team group].
+ Member of Cs working groups: [http://www.couchsurfing.com/group.html?gid=10128 Events & Outreach - Event Organizers] & [http://www.couchsurfing.com/group.html?gid=3727 couchsurfing Wiki]
+ Wikiholic; editing Wiki's of among others [[Utrecht]], [[Netherlands]] and [[Dutch ambassadors]]
+ Organisation of meetings in Utrecht
+ trying to keep track on Dutch groups and Ambassadors groups, posting there when necessary
+ Trying to keep contact with other communities in the Netherlands
+ Trying to go to meetings in and outside Utrecht when I can

[[:cs:users/SANNEBONGERS|Sanne Bongers]]
+ Moderator of [http://www.couchsurfing.com/group.html?gid=1348 Utrecht CS group] and [http://www.couchsurfing.com/group.html?gid=14572 Dutch lessons in Utrecht group].
+ Organiser of the Utrecht CS Dutch Lessons.
+ Organiser of several events in Utrecht.
+ Going to many meetings in Utrecht and trying to go to meetings in other communities.
+ Spreading the word, be a good host/surfer.

[[:cs:users/KIWIA|Tim Straatsma]]
+

=====[[Den Haag]]=====
[[:cs:/LIN.|Linda]]
+

=====[[Groningen]]=====
[[:cs:users/GPIKKIO|Giuseppe Cimo']]
+ Active Couchsurfer.
+ Moderator of the [http://www.couchsurfing.com/group.html?gid=4416 Groningen CS group].
+ Moderator of [http://www.couchsurfing.com/group.html?gid=12745 CS Groningen Organization group].
+ Moderator and active member of many groups.
+ Event organizer in [[Groningen]].
+ Editor of the [[Groningen]] CS Wiki page.
+ Member of the [http://www.couchsurfing.com/contact.html Contact Us Team].
+ Member of the [http://www.couchsurfing.com/group.html?gid=7043 Groups Management operators].
+ Member of the [http://www.couchsurfing.com/organization.html?gid=4401 Location Fixing Team].
+ Member of the [http://www.couchsurfing.com/group.html?gid=3581 New Member Welcome group].
+ Member of a number of CS Organization Working Groups.
+ ([http://www.couchsurfing.com/group.html?gid=6 Old]) translator of the CS site.
+ Mentor for new ambassadors and volunteers in the north Netherlands.
+ CS addicted :)

=====[[Maastricht]]=====
[[:cs:/LEONAH|Leona Reuter]]
+

=====[[Eindhoven]]=====
[[:cs:/KONL|Konstantin Youdenko]]
+

=====[[Leiden]]=====
[[:cs:users/LINFORCER|Tommy Quist]]
+

=====[[Haarlem]]=====
[[:cs:users/COUCHISTA|Klaas]]
+ moderate Haarlem group at http://www.couchsurfing.com/group.html?gid=6774
+ organise meetings such as http://www.couchsurfing.com/meetings.html?mid=9214
+ maintain CS Wiki page about Haarlem at http://wiki.couchsurfing.com/en/Haarlem
+ promote CS in my social network

=====[[Delft]]=====
[[:cs:users/vontaks|Lukas Taks]]
+

=====[[Dordrecht]]=====
[[:cs:users/REMUS86|Remco Matthias Kwint]]
+

=====[[Oss]]=====
[[:cs:users/lourenssenm|Maikel Lourenssen]]
+

===Other Ambassadors===

[[:cs:users/onsplekkie|Maarten, Ilse + Lilou Duijvesteijn]] (De Lier) (Family)

[[:cs:users/CYDOREN|Cynthia Doren]] (Amsterdam) (Nomadic)

[[:cs:users/IPELLEBOER|Ineke Pelleboer]] (Oldelamer) (Nomadic)

[[:cs:users/SERENDIPITOUS|Serendipitous]] (Roger Thompson) (Schaijk) (Nomadic)

[[:cs:users/LAO|Laurence Carrier-Desjardins]] (The Hague) (Nomadic)

[[:cs:users/SUPERANDERSAO|Anderson Ferreira]] (Rotterdam) (Nomadic)

[[:cs:users/NAT-CHO|NAT-CHO]] (Amsterdam) (Nomadic)

[[:cs:users/jeroenek|Jeroen Geerdink]] (Nomadic)

==Ambassadors meetings==

=== Calendar ===

Ambassadors and other volunteers organize many meetings and happenings all around the country. Check the Dutch CS events on our [http://www.google.com/calendar/embed?src=couchsurfingnl%40gmail.com&ctz=Europe/Amsterdam Calendar]

=== Minutes ===

Here you'll find reports of the meetings with the City and Country ambassadors in the Netherlands.

[[Minutes 1st Dutch Ambassadors meetup]], march 15th 2008, Utrecht

[[Minutes 2nd Dutch Ambassasors meetup]], june 14th 2008, Utrecht

[[Minutes 3rd Dutch Ambassasors meetup]], september 6th 2008, Groningen

[[Minutes 4rd Dutch Ambassasors meetup]], january 10th 2009, Oss

[[Minutes 5th Dutch Ambassasors meetup]], september 27th 2009, Haarlem

== Dutch Ambassador Welcome kit ==

The [[Dutch Ambassador Welcome kit]] has usefull information for new ambassadors in the Netherlands.

== Things to do==

[http://wiki.couchsurfing.com/en/Ambassadors#Tips_for_Ambassadors Tips for ambassadors]

'''Wiki Netherlands'''

The [[Netherlands|Dutch wiki page]] is in progress! Please feel free to add any useful information!
[[Category:CS Organization Netherlands]]
[[Category:Netherlands]]

Dutch Ambassador Welcome kit

2009-10-15T12:11:59Z

Matrixpoint:

Inspired by the Belgian new ambs kit

==Warm welcome==

You reading this is good news! Everytime someone reads this [[Dutch Ambassador Welcome kit]] it means our active cs family is growing! From now on you’re an official cs Ambassador. In order to help you with your new tasks as an Ambassador this document contains heaps of helpful information. Here you’ll read what it entails to be an efficient cs Ambassador, how the [[Netherlands]] CS organisation works, and some tips on how to stay in the right shape! We advise to read it carefully and thoroughly.

==What it entails be a CouchSurfing ambassador==

Being an ambassador in the [[Netherlands]] should be a fun and interesting experience to be enjoyed. This document contains a the guidelines, but as most things in life it’s what you make of it yourself.

===Description===

First and foremost Ambassadors promote the values that embody the Couchsurfing Spirit. City Ambassadors are also the voice and ear to their local community, and source of information for all the members of their local community.

===Responsibilities===

Most City Ambassadors contribute at least 10 hours per month but this varies greatly from person to person. We want to make sure all Ambassadors love what they do. Please always feel free to ask for help, ask your other city ambassadors in the group or send a private mail to your country ambassador.

The '''role''' of the City Ambassadors is to be of service to CouchSurfing members and to be of service to the local community. Ambassadors are volunteers committed to helping others.

'''As travellers, hosts, surfers, and volunteers, Ambassadors strive to'''
* Promote respect and tolerance for individuals and cultures
* Promote cultural diversity and awareness
* Promote equality, inclusiveness, and friendship
* Promote honesty and fairness

'''In addition, in our role as volunteers Ambassadors strive to:'''
* Promote personal and professional integrity
* Promote the pursuit of excellence
* Promote teamwork

'''Ambassadors Code of Conduct'''
Our behaviour as travellers, guests, hosts, and volunteers is a direct reflection on CouchSurfing. Therefore Ambassadors will be held to the highest standards of personal and professional conduct. Ambassadors must agree to the [http://www.couchsurfing.com/amb_ethics.html code of conduct]

==Duties City ambassador==

There are four levels of ambassadorship: [http://www.couchsurfing.com/amb_levels.html City, Country, Global and Nomadic]. The duties of city ambassadorship is defined below. The explanations of the other [http://www.couchsurfing.com/amb_levels.html levels of ambassadorship] can be found on [http://www.couchsurfing.com/amb_levels.html the couch surfing website]. If you have any questions feel free to contact another ambassador (country or other).

It could be that your community is already active and has ambassador(s), in that case we recommend you to contact your fellow city Ambassadors and see where you can help out.
There’s a possibility that you might be the first ambassador of a city (check the [[Dutch Ambassadors ]]wiki). In that case we recommend you to contact a nearby fellow ambassador or an ambassador mentor and ask them any questions you have. They are more then willing to help you out.

===Organise local events===
Most active communities are organising meetings. This could be a set weekly meeting ([[Amsterdam]] Friday), ([[Rotterdam]] Tuesday and Saturday) or a monthly meeting ([[Utrecht]], [[Enschede]], [[Maastricht]], [[Amersfoort]] or [[Groningen]]) or just random meetings as in [[The Hague]].

There are many ways to set up a meeting. For tips and tricks check [http://www.couchsurfing.com/wiki/How_to_make_a_good_meeting how to make a good meeting page].

=== Moderator of your City group ===
A new CS city amb should become moderator of his/her city group. This does not happen automatically. You kindly need to ask the moderators of your city group to make you co-moderator. Moderators can be your fellow city Ambassadors or it can be a normal moderator who once started the group. If they don´t add you to the group or you get a negative response send a message to [http://www.couchsurfing.com/contact.html Contact Us] and explain the situation.

Your role as a moderator is firstly to provide visitors of the group a quick access to the ambassadors in your City. Secondly, City Ambassadors are responsible in keeping their local community alive, providing info and more. This includes defining group guidelines, managing/raising polls and establishing Google events calendars if required.

=== Communication ===
There are many ways to communicate with your fellow active members. The idea is to build up or keep continuing a strong local community. It might therefore be essential to keep your fellow active members involved and informed about new events, meetings and other initiatives.

=== New member welcome ===
A good way for an ambassador to welcome new members in your community is by joining the [http://www.couchsurfing.com/group.html?gid=3581 new member welcome group]. Through the [http://www.couchsurfing.com/group.html?gid=3581 new member welcome group]you’re able to find out which new members have joined your community. To warmly welcome new members and show them what is happening in your community with a welcome message can be appropriate.

Once you join the [http://www.couchsurfing.com/group.html?gid=3581 new member welcome group] you will receive extra tools on your profile to send out welcome messages.

=== Visit other local meetings ===
You’re always welcome to visit any of the local meetings. May you be looking for some new ideas, want to get to know your fellow active members, please do not hesitate to visit one of the local meetings.

=== Participate in the Netherlands CS organisation ===
Together with all the ambassadors we work on building this sustainable network, the Netherlands CS organisation. All ambassadors and active CS members who are interested are welcome to join. For more info on the Netherlands CS organisation check below.

=== Ambassador groups ===

As an ambassador you automatically become member of:
*[http://www.couchsurfing.com/group.html?gid=2125 Ambassador’s Public]
*[http://www.couchsurfing.com/group.html?gid=1668 Ambassadors Private]
*[http://www.couchsurfing.com/group.html?gid=4407 City Ambassadors (if you have become a city ambassador)]
*[http://www.couchsurfing.com/group.html?gid=4410 Nomadic Ambassadors (if you have become a Nomadic ambassador)]

Feel free to explore the topics that are discussed in these groups. A good start are the flagged posts of the Ambassador’s Public and of Ambassador’s Private groups.

=== Extra Features on CS website ===
Ambassadors get acces to some extra features on the CS website.

*First, you get an extra [http://www.couchsurfing.com/ambassadors_home.html Amb tab] in your navigation. This amb page gives all the information about ambassadorship and other ambassadors in the world and includes the groups of your community.
*Second, you can check where recent sign ups heard about CS in the [http://www.couchsurfing.com/amb_where_hear.html where did recent sign ups hear about CS?] page. You also see this feature on CS profiles in the personal info.
*Third, as an ambassador you now have extra possibilities with [http://www.couchsurfing.com/statistics.html the statistics]. As an amb you can check more specific regional statistics, per country. There is a selection box on the top of the page where you can select your country of choice (for instance, the Netherlands).
*Fourth, you can mark CS profiles as having an [http://www.couchsurfing.com/exotic_couches.html exotic couch]. When a CS member lives in a places which brings a special element to a CS experience you can mark his/her couch as [http://www.couchsurfing.com/exotic_couches.html exotic]. For instance when somebody lives in a boat or in a remote area in the nature this could be an [http://www.couchsurfing.com/exotic_couches.html exotic couch]. People who look for special CS experiences can look up these members.

Explore the features and use them for you community.

== The Netherlands CS organisation ==
The Netherlands CS organisation team meets approximately once every three months. All the minutes of the Netherlands CS organisation you can find in the in the Dutch ambassadors wiki and in the Netherlands CS organisation wiki. Please read all the meeting minutes, they contain valuable information!!

You’re automatically enrolled in this group after you have obtained your Ambassadors status. You’re more than welcome to participate in any of the upcoming meetings.

In order to collaborate efficiently and effectively, the Netherlands CS organisation uses various communication tools:
* [http://www.couchsurfing.com/group.html?gid=5031 The Netherlands CS organisation group]: Discussions, remaining in touch and exchange of ideas. New ambassadors and active CS members will be added to the list
* [http://groups.google.com/group/couchsurfingnl?hl=en The Netherlands CS google group]: All CS NL documents should be sent/posted here. New ambassadors and active CS members will be added to the list.
* The[[ Netherlands ]]wiki: It’s an open source of information and can be used and adapted even when the site is down. Feel free to add information (especially in the [[Dutch Ambassadors]]).
* [http://www.google.com/calendar/embed?src=couchsurfingnl%40gmail.com&ctz=Europe/Amsterdam The Netherlands CS google calendar]: All events happening in the Netherlands can be found in the google calender
* Datum prikker: used for setting up new meetings

=== Other Netherlands Ambassadors ===
There are Ambassadors in all regions of the Netherlands. The [[Dutch Ambassadors]] and information about the CS NL organisation meetings (minutes) can both be found in the [[Dutch Ambassadors ]]wiki. Once again, please read all the meeting minutes, they contain valuable information!!

Everyone is encouraged to be on the lookout for people that would make a great ambassador or be valuable on a working group, and encourage them to apply or join!

=== Ambassador mentor ===

As a new ambassador we understand that you might still have questions after reading the Dutch ambassador welcome kit. To help you with any questions you might still have, there are 3 ambassador mentors. We divided the country up in North, Middle and South. Each ambassador mentor is a mentor to new ambassadors in his or her region.

The regions are divided accordingly:
*North (Friesland/Groningen/Drenthe/Overijssel): [http://www.couchsurfing.com/people/gpikkio Giuseppe (GPIKKIO)]
*Middle (Noord-Holland/Zuid-Holland/Utrecht/Flevoland) [http://www.couchsurfing.com/people/lizzie82ish Liza (LIZZIE82ISH)]
*South (Zeeland/Brabant/Limburg/Gelderland): [http://www.couchsurfing.com/people/lourenssenm Maikel (LOURENSSENM)]

Feel free to contact them if you have any questions

=== Tips for meet ups & activities ===
I am sure you already have a great deal of experience in organising meetings and events. The possible fellow Ambs in your city will probably have a way of organising things. It would be good to contact them about their plans.

In the [http://www.couchsurfing.com/wiki/How_to_make_a_good_meeting how to make a good meeting page] you can find extra tips and tricks on organising meetings and events.

CS has business cards you can customize and have printed or print yourself. This is a great help while promoting CouchSurfing. Simply [http://www.couchsurfing.com/business_cards.html download a file from here] and print out on your own.

==Dealing with security issues and problem resolution procedures, etc.==

VERY IMPORTANT before posting ANYTHING linking to a member read this one: [http://www.couchsurfing.com/group_read.html?gid=1668&post=1278659 Reminder about user privacy]

Basically the approach to any problems you might have would be to either directly contact your Country Ambassador or send a message to a member of the Leadership Team using the standard [http://www.couchsurfing.com/contact.html Contact Us form].

DO NOT USE THE GROUPS!!!

Most often a member of the Contact Team will then advise you of the next steps to take or of the answer you need. Familiarise yourself with the contents of the [http://www.couchsurfing.com/contact.html Contact Us form] including familiarity with the range of items in the pull down menu labled Communication Type.

For problems (you have) with another member of CouchSurfing you can directly contact he Member Dispute Safety Team (MDST) by selecting "Problem with another member" in the [http://www.couchsurfing.com/contact.html Contact Us form].

=== Dealing with crimes such as: theft, abuse, and/or any forms of harassment. ===
What are the official procedures, whom do we contact, and in what order?
Be prepared! Read the [http://www.couchsurfing.com/tips.html Tips for Surfers and Hosts].
* If necessary contact the local police / ambulance USE YOUR COMMON SENSE!!
* If other couchsurfers are involved, contact the Safety Administrator through the [http://www.couchsurfing.com/contact.html Contact Us form]. Tell them as many details as possible about your experience. CouchSurfing will investigate and determine the best course of action. If necessary leave a negative reference.
* Dealing with Dating requests: see [http://wiki.couchsurfing.com/en/Handling_dating_requests Handling Dating Requests]

== Useful Links ==
:[[Dutch Ambassador Welcome kit]] (this Document)
: [[Dutch Ambassadors ]]wiki
: [[Netherlands ]]wiki
:[http://www.couchsurfing.com/group.html?gid=5031 The Netherlands CS organisation group]
:[http://www.couchsurfing.com/amb_levels.html The Levels of ambassadorship]
:[http://www.couchsurfing.com/group.html?gid=3581 New member welcome group]
:[http://www.couchsurfing.com/contact.html Contact Us form]
:[http://www.couchsurfing.com/wiki/Answers_to_some_common_Contact_Us_Questions Frequently Asked Questions]
:[http://groups.google.com/group/couchsurfingnl?hl=en CS NL google group]
:[http://www.google.com/calendar/embed?src=couchsurfingnl%40gmail.com&ctz=Europe/Amsterdam CS NL google calendar]

== Don’t worry be happy ==
Being an Ambassador can be a bit overwhelming. It’s really important that you have as much fun as possible. Hereby some small remarks on how to avoid stress as an ambassador:
* Do what you love. Volunteering is meant to be fun. If greeting turns you on, greet. If you love to host, host. If you enjoy taking people out and about, do that! Whatever floats your boat: every contribution counts!
* Recharge your batteries. If you start feeling drained, take a break.
* Network. Share ideas, thoughts and frustrations with other CSers you get along with.
* Portion Control. Basically, don't bite of more than you can chew. You might get a nasty case of indigestion!
* Participate. Join the discussions and make your voice heard.

= Good luck!=
We wish you all the best. We’re a team all together so if you have any questions please don’t hesitate to contact one of us. We hope to see you around! The Netherlands is smaller then you think!

[[Category:CS Organization Netherlands]]
[[Category:Netherlands]]
[[Category:Welcome kit]]

Minutes 1st Dutch Ambassadors meetup

2009-10-15T12:11:14Z

Matrixpoint:

1st meetup of [[CS_Organisation_Netherlands]]

Present:
Henri, Aldo, Paul, Pieter, Harold, Rose, Ramon, Liza, Jasper, Guiseppe, Esly, Maikel.

MEDIA
There is a need for guidelines, what can we tell to the media. Which image do we want to spread? Some people would love some words (in Dutch!) which we can use in our media contacts. Maybe we should have one person in charge for media issues? Some people have the experience that whatever you tell, the media will end up with focussing on a free place to sleep. It can help to point to couchsurfing as a trend. But in the end, it looks like that members are not very much affected by the news. Many members who sign in during a media hype will not get active. It looks like the system is filtering itself!

SAFETY
This is an important issue for many people. Ambassadors want to protect the members. How can we avoid that people have more profiles? The safety team can check this. There is always a (automatic) check before people can sign in. and, if someone makes a report, there can be a new (manual) check.
If someone reports another member to the police, he or she will be banned (the victim should send the report of the police, as ambassador you can only support him/her by doing so, you can not report an abuser to the safety team). It turns out that in real life, the community itself also deals with ‘abusers’. You, as an ambassador, can always warn people to be careful.
There are still people working on a kind of Black List, but it is not clear if and when this will be implemented.
One of the changes made recently is that edited references do not get automatically back on top. This makes it more difficult for members with a bad reference to ask their friends to bring the negative comment down by editing their references.
The most important safety check members can do by themselves is the verification check. If someone is verified, there is not a big chance that people are not trustworthy. Recent research concluded this as well. Vouching can also say something about the person, but is much less reliable.
Only country ambs can see hidden profiles. In case you have doubts about a specific person (with a hidden profile for example), you can contact Aldo about safety issues with this member. At the moment, there are no suspected members living in the Netherlands.

MEETINGS
We will make a list of big national meetings. Maikel will create a calendar for Dutch events. About monthly meetings, on the one hand it would be nice to choose different days in different cities. On the other hand, it seems not very likely that people from Den Haag and Groningen will visit each other (small scale) monthly meetings.
Upcoming big events;
- 2-4 Gig Swapping (Utrecht)
- Queensday. Problem is to find enough hosts in Amsterdam. Organisation has no obligation to find hosts, you can promote people to look for hosts outside Amsterdam. Discussion will be continued online.
- 21-6 Midsummer Night in Utrecht
- Sinterklaas (Rotterdam)
We can extend this by an online discussion!

WIKI
Jasper created a wiki page about Utrecht. He will coordinate other pages for the Netherlands as well. But he needs input from others!

CS ZONES
Paul and Aldo present CS Zones. This will be pages about places, maintained by ambassadors. It is very premature at the moment, but it looks very cool!

FLAG / STATUS
Does this flag on your profile really mean something? It makes you visible. People can turn easily to ambassadors with questions and remarks. He or she can also connect active people in order to get things organised. (But being an ambassador is not necessary for this!). Ambassadors are mainly there because some structure is needed.

NEXT TIME
Next ambassadors meeting will also take place in Utrecht. We will set a date (after Queensday) later. Liza and Jasper will host us in their new house. For this meeting, we should also invite other ambassadors, make an agenda and we prefer a calmer place (like a house!). It might be a good idea to have another meeting about the Queensday Meeting. But this can also be online… After the next meeting in Utrecht, we can go on tour! So organise a weekend in Groningen, Maastricht, Enschede and even Oss!

Points to be discussed next time:
- Ambassadors communication and organisation
- Goodies
- Real life CS Promotion
- Media Contacts
- Big meetings and matching regular meetings.

[[Category:CS Organization Netherlands]]

Minutes 2nd Dutch Ambassasors meetup

2009-10-15T12:11:01Z

Matrixpoint:

2st meetup of the [[CS_Organisation_Netherlands]]

location: J & L's crib (Utrecht)

'''Present''': Giuseppe (city Ambassador Groningen), Liza (city Ambassador Utrecht), Jasper (city Ambassador Utrecht), Maikel (active member), Kim (Leiden representative), Menno (Amsterdam representative), Martine (country ambassador Belgium), Chris (city ambassador Aachen, Germany), Aldo (Global ambassador).

'''Absent with notification''': Harold, Rose, Ramon, Esly, Henri, Tim

'''Absent without notification''': Shilp, Klaas, Konstantin, Sannie, JP1978, Joris, Paul, Martiniman, Eleanor.

==Welcome to new ambassadors==
Everyone told why they became active, what they are active with and what working groups they are involved in

==Queensday==

Important people are missing for a good evaluation.

some short observations:

- We started too late

- To the outside the list of sub-event looked very chaotic

- We were lacking a big central event

- There were too many things at the same time

- In general we were very good at brainstorming and coming up with a lot of submeetings but lacked the ability to focus on a short list of events.

==Mission and goals==

- Get to know each other

- Organise things together

- Help to get travellers in the Netherlands off the beaten track and to put the Netherlands in a broader perspective

- Give a framework for new ambassadors with information, advice, help on a local job and answers to questions

- Motivate each other to get a momentum

- Reaching out abroad

- Help finding solutions for problems together

- Finding creative ways to get new members active

==Ways to reach our mission and goals==

- mentorship (new ambassadors get help from an experienced ambassador)

- Regional coordination (west / south / north)

- Coordination for 'out of border activities'.

- Recruiting new ambassadors

- Making activities of the beaten track

Who: will be discussed online.

==Intern organisation==

How do we organise ourselves?

- Rotating locations

- The people from the host location will present theirselves and will arrange minutes

(The next location will be [[Groningen]])

- in every meeting there should be time for a brainstorm about other meetings like we did today

==Inactive ambassadors==

Henri should get into contact with inactive ambassadors to find out if they are really inactive and if so if the want to stay ambassador. Possible inactive ambassadors are Martiniman (Eindhoven), Joris (Amsterdam) and Eleanor (Rotterdam).

Henri should invite all nomadic ambassadors within the Netherlands into the Netherlands organisation group and should ask if they want to be more involved.

==European coordination==

- google-calanders can be usefull for internal coordination, not for reaching out abroad.

- It is good to have 1 or 2 representatives from neighbouring countries at our meetings.

- A meeting of country ambassadors in the North-west of Europe might be usefull.

- A meeting of ambassadors near each others border might be usefull.

- A good way of keeping track of each other is joining eachothers groups. Most of us don't want to interfere with discussions in other peoples groups (allthough nobody seems to mind if that would happen in their own group).

==Ambassadors in conflict==

how do deal with questions about negative references:

- There is a group about support on writing references, it could be usefull to refer people to that group

- In doubt always ask to contact the safety team.

- On a negative reference, always be short and factual, not emotional.

==Business cards==

Several people seem interested in them. We will check in our local groups if other members are interested so we could order a lot at the same time on national scale.

==Fundraising==

There are diffent opions on this subject. Important is always to be open about what you use the money for and to use the money only for specific perposes so not for something general.

[[Category:CS Organization Netherlands]]

Minutes 3rd Dutch Ambassasors meetup

2009-10-15T12:10:38Z

Matrixpoint:

3rd meetup of the [[CS_Organisation_Netherlands]], Saturday 6th of September, Groningen

Attendees: Giuseppe (host and chair, Groningen), Liza (Utrecht), Chris (Aachen), Gerard (Rotterdam and surrounding), Maikel (Oss), Ramon (Amsterdam), Henri (country amb), Rose (country amb), Aldo (admin), Paul (Rotterdam), Tommy (Leiden), Menno (Amsterdam), Esly (minutes, Enschede)

=Introduction=

· Please fill in the Dutch Ambassadors wiki with the tasks you are doing or would like to do. If you have problems with the wiki, please contact Jasper. He can help you! http://wiki.couchsurfing.com/en/Dutch_Ambassadors

=Already discussed and to be finalised=

· At the last meeting, we decided that new ambassadors might need some support. Ramon sends some information to new ambassadors now. Henri and Rose will write some kind of tool kit to help the newbies to get to know our group and help them to get active as an ambassador. Also, it is decided that we will introduce some ‘buddies’ for new ambassadors. Giuseppe (for the northern part), Liza (for the middle) and Maikel (for the south) will be the first persons for new ambassadors to go to. What does of course not mean that others are not allowed to help or motivate them!

· We should try to activate inactive ambassadors. In Australia they send a very nice message to inactive ambassadors to find out what they are doing. Henri and Rose will send a reminder to our inactive colleagues. If you think an ambassador is inactive, please write to Henri or Rose so they can send that person a message.

Aldo has a lot to say about this topic. If an ambassador is not coming to the meeting, it does not mean he or she is an inactive ambassador. Country ambassadors should have an idea who of the not-active group members, are active in their local community though. If ambassadors are inactive in both the ambassador groups, and in their local community, we can write that the ambassador team in CouchSurfing to ask to have a look at this person and see whether he or she is the right person to be an ambassador. We can even set some rules of what we think an ambassador should do. If a person doesn’t meet those ‘rules’ we can ask the management team to take them out. In the next months, the ambassadors will become a focus point for the CouchSurfing organisation. So it might be that some standards or rules for ambassadors will change.

To keep people up to date about what’s going on in the Netherlands, we might think about making some kind of newsletter in which every ambassador can write a bit about the activities in his/her city.

· Regarding the emergency couchlist. Some of those lists offer people an emergency couch, others only advice people. Aldo knows the system in CouchSurfing will change on this topic, so people might still be able to find their host. Also, the site is almost always up, so you can doubt how necessary it is. We decided to wait for the improvements on the site and then have a further look at it.

· Paul and Aldo give us an update about CS Zones and City Surfing Pages. There will be two different things implemented, first CS Zones, which is really one specific location where CouchSurfers meet or get together regularly. The second is City Surfing Pages. Those are under construction, but will give information about a city. The first page will be a kind of magazine where you can post news about coming meetings, pictures of passed ones and so on. The other pages will become more static. At the next meeting, Paul hopes to be able to show us some examples.

=Netherlands Group Coordination=

· Considering the Dutch CS-groups, we decided to base the structure on provinces. Giuseppe will try to make a clickable map to put on the Netherlands main group page, so that people can immediately click to the region they are looking for.

Inactive groups will be deleted (after talking to the moderator about it), double ones can be put together. A moderator should mainly literally moderate. He or she can also welcome new group members, but this should depend on the group and the person joining. Just use your common sense to decide whether you think it is needed or not!

Ramon will continue this job. If you have suggestions or ideas, please contact him.

· Giuseppe will write some manual for our group communication.

§ For discussions, use the CS Group

§ For amb-meetings, CS Events, if people are added we can also use that to communicate with the group.

§ For documents, use the Google group

§ For things that are also open for outsiders, use the wiki pages

If new members are added, the other members of the group should be informed about that. To prevent a too big amount of members of the organisation group, it seems to make sense to take only foreigners in who are related to the Netherlands (like Dutch Nomadic Ambassadors abroad, or people like Chris who work a lot together with Dutch cities), in general, one representative of our neighbouring countries (next to the ones we have very direct connections with), should be enough.

· It is possible to get a third country ambassador. Giuseppe says that being active in CouchSurfing and getting an idea of the international situation can also be done in some workgroups.

Some different tasks for country ambassadors are mentioned.

§ They should have an overview of the city ambassadors and take care about them

§ They are the link between the Dutch organisation and the outside world.

§ They have a motivating role

§ It would be nice if the country ambassadors can develop some vision where we want to go to with this organisation group.

Rose says that since she applied, so many things changed in Amsterdam. Her help is needed in Amsterdam for now. Paul advices to ask active members to help, also without a flag.

Aldo differentiates three kind of jobs for country ambs. The first one is mainly online, in taking part in group discussions, promote and represent the Netherlands in international groups, greeting people and so on. These jobs seem to suite Rose. The second part is meeting people, show your face, promote CouchSurfing on meetings and so on. This is what Henri is good at. The thing that is missing is someone who has a broader overview, who can take care about the organisational part and brings up things among ambassadors.

Both Liza and Giuseppe thought about applying as a third country ambassador. Giuseppe has his doubts for being not Dutch and is very likely to leave the country in about two years. Everybody, including Giuseppe, will be very happy if Liza will apply for the third country ambassador position. The situation in Utrecht is very stable with Jasper as active city ambassador. Liza will think about it and inform us before the 9th of September, the next deadline for country ambassador applications. If she will apply, Giuseppe can always help if things need to be done.

=Event organisation=

· Due to a lack of time, we will discuss this further online. Please write some words about your experiences with events and organising them in the CS group. In this way, we can all learn from each other.

Next Dutch ambassadors meeting will be held in Rotterdam, in the last weekend of November. This weekend, the big international Sinterklaas Meeting will also take place in this city. Paul will organise our meeting, more details will follow by then!

=Decisions taken:=

1. Henri and Rose will develop a toolkit for new ambassadors

2. Giuseppe, Liza and Maikel can act as buddies for new ambassadors

3. Henri and Rose will send a reminder to inactive ambassadors

4. Everyone can/should write Henri or Rose if you think an ambassador is inactive

5. Regarding an emergency couch list, we will wait till the system on the main page is improved

6. The Dutch CS Groups will get based on provinces

7. Giuseppe will try to develop a clickable map for the Netherlands Group page

8. Giuseppe will write a manual about communication in our group

9. If new members are added to the group, we will get informed about that

10. Liza will think about applying as a third country ambassador

11. Next meeting will be in Rotterdam, in the weekend of the Sinterklaas meeting

[[Category:CS Organization Netherlands]]

Minutes 4rd Dutch Ambassasors meetup

2009-10-15T12:10:22Z

Matrixpoint:

Minutes of 4th meetup of the [[CS_Organisation_Netherlands]], Oss January 10th 2009

Present: Liza (Country amb), Maikel (Oss), Willem (Rotterdam), Giuseppe (Groningen), Jasper (Utrecht, not.), Timz (nomadic, Utrecht), Sanne (Utrecht), Klaas (Haarlem), Tim (Utrecht), Henri (country amb).

absent with notice: Rose, Marten, Jeroen, Menno, Esly, Tommy, Gerard, Paul, Aldo, Rossi

==1. Minutes last meeting: ==
decisions taken:
– click able map: not possible
– communication manual: better as a flagged post, it changes quite often

==2. Google calender==
We will not promote the google calendar, it is better to centralize information, it is better to focus information in the events page. Liza will post to the brainstorming group that you can be alarmed if there is already a meeting your region if you make a meeting for a certain day.

==3. Working groups==
There doesn't seem to be a need for it yet. If there is a subject that needs a workgroup we can start one for it.

==4. Editing groups==
No action is taken so far. Giuseppe has the tools to edit groups. Giuseppe can start according to the decisions taken on the previous meeting. Any 'tricky' cases can be discussed among the taskforce about this topic (Giuseppe, Ramon, Liza, Tommy, Jasper).

==5. Nomadic ambassadors==
The country ambassadors sent out an email to the Dutch nomadic ambassadors what their plans were. This could have been more carefull. Rose still have to report the answers.
A lot of nomadic ambassadors in the Netherlands seem to be having a quite steady base in the Netherlands, and could as well be city ambassadors. We try to get into contact with nomadic ambassadors (like city ambassadors), we should do this as decentralized as possible.

==6. Posting in each other groups. ==
Best is posting just in the city and country group. In other city groups maybe there can be postings about traveling there (so there is a direct link). Meetings set up to be very big are of course a exception, there's no problem of posting them in other groups. About other cases you can always contact moderators of a group.
If you see people signed in on meetings who have to travel there (ig on big events), it can be smars to post to people to suggest to travel there.
For repeating of messages, please add new information.

==7. Money==
Investigation about what a legal entity requires can be very welcome, but there is a big fear that creating a legal entity can create much more fuzz than we want to and it doesn't seem strictly necessary. Liza will post about this in an ambassador group.

==8. Wiki==
Please add info about yourself on the wiki, if you don't know how to use the wiki, ask Jasper.

==9. Welcome kit==
Giuseppe made some corrections, Liza and Henri will check them out. Safety issues will be delt with by contact us, not by the country ambassadors.

==10. Queensday==
Best way would be to focus on several smaller meetings (the box of chocolate strategy) but connect them all by making them all start with the word 'Queensday-week'.
The rest is up to the organizers of the several events.

==11. New members==
be carefull of facebook.

==12. Rondvraag==
We would love to hear more about what country ambassadors are doing, Rose is very absent in the ambassadors group.
There is just a small group of people active. Meeting in person has an extra value. We try to keep the meetings as open as possible for new people, also inviting active people without a flag.

* next meeting: in the beginning of April in a more informal setting

==13. Meeting Annet==

==action list:==

everybody: (if needed) add you info in the ambassadors wiki page

Liza: post in the brainstormgroup about double meetings

Rose: report the answers to the messages to nomadic ambassadors.
everybody: get into contact with nomadic ambassadors in your region (if you don't know them yet), if an ambassador appears to be inactive, get into contact about it with a country ambassador.

Liza and Henri: update the welcome kit.

Liza: post about money in ambassador groups.

All country ambassadors: inform on progresses made.

[[Category:CS Organization Netherlands]]

Minutes 5th Dutch Ambassasors meetup

2009-10-15T12:09:51Z

Matrixpoint:

Minutes Amb-meeting Haarlem zo 27-9-2009

5th meetup of the [[CS_Organisation_Netherlands]]

===Present===
Menno (city amb. Amsterdam), Klaas (city amb Haarlem), Gius (city amb Groningen), Henry (country amb), Maikel (city amb. Oss), Linda (city amb Den Haag), Jelly (city amb Amsterdam), Liza (country amb, chair), Floris (Wognum), Sanne (city amb Utrecht), Pieter (Leiden), Gerard (Bergschenhoek, Rotterdam region), Sytse (Arnhem), Jasper (city amb Utrecht)

===Absent with notice===
Konstantin (city amb Eindhoven), Rose (country amb), William (Breda)

==1. Introducing each other==
a short introduction round

==2. CS newsletter==

Henri: had contact with Meredith from CS homebase in SF a while ago about a plan to have a newsstream on the website. It is a pilot, other countries are already involved.

We want to be involved, we were working on a newsletter anyway. We made a group of people who will work the plans out.

===Tasks===
editing, scouting (finding people and info), journalists

===Interested===
Sanne, Maikel, Jasper, Sytse, Linda & Floris

==3. CS NL Foundation==

Floris was thinking about having a foundation. He made a list of benefits and downsides on which we added some things.

===benefits===
* looks more professional
* possibility for sponsorship
* possiblity for referencing for jobless people who want to volunteer
* contact with local gouvernments might be easier
* improves legal status (responsiblities)
* possiblity to get insurance

===Downsides===
* extra costs of administration (how much? tens or hundreds or euro's?)
* boring work
* more responsiblities
* might look overprofessional which might not fit with the general atmosphere on couchsurfing
* couchsurfing international doesn't back it up (or is this a benefit?)

===other ideas===

* Would it be possible to do it on a European base?
* We decide to do more research
* Floris, Linda & Henri will do this.
* Next meeting there will be a report about this.

==4. New ambassadors / application procedure==

Liza made a presentation about the procedure that just finished, you can find it on the [http://groups.google.com/group/couchsurfingnl CS NL google group]

The future of this procedure is unclear

When the new round starts Liza will notify people in active cities without an ambassador.

==5. CS NL outside of Randstad & Bigger cities==

Jasper: Couchsurfing is slowly spreading outside of the Randstad, but is still mainly focussed on cities. Do people agree with this problem and know a way to solve it? Answer to both questions seem to be yes. We also agree that it is a task of us to help travellers to get out of the beaten tracks.

Menno, but also others, already have plans for meetings in the countryside

The news letter might help extra to promote lesser known places.

It also might help to drag people from smaller places to big cities, when people in the big cities know them it is easier to visit them.

Idea: organise several (like every 3 months) 'invasions' to small places and see how that works.

We will start a topic about this (countryside invasions) on the CS NL group, several people will come with ideas and are free to organise them.

==6. Groups reorganisation==

Reorganisation is almost finished.
The 'Holland'-group will be put in a subgroup 'archived subgroups of the Netherlands'

We have some NL-subgroups left which are not province-groups. We decide to not put them in a new subgroup. The list of subgroups of the Netherlands is not chaotic anymore so it is not a problem that those subgroups are there.

Not every province group the right moderators yet. The people involved in the reorganisation will fix this soon.

==7. New developments in CS==

Some people gave some updates in the current situation.

==8. WVTTK==

===Events powerpoint===
Maikel made a very usefull powerpoint presentation about how to use the events-page
You can find it [http://docs.google.com/present/view?id=0AeBqhUHENOo_ZGQ2M2prOGhfNDNna3pyZGhnZA&hl=nl here]

===Greetings===
At this moment the following Dutch people are greeting new members (local, national or globally):

Klaas (local)

Maikel (national/global)

Henri (? National)

Liza (local and national)

Giuseppe (local)

Linda (local, just applied)

Other greeters (not at the meeting):

Astrid from Eindhoven

Shilp from Delft

Erik from Arnhem

The following people said they also want to greet:

Pieter

Jelly

Sytse

Floris (locally)

==Action list==

- Sanne, Maikel, Jasper, Sytse, Linda & Floris: working out the idea of the newletter

- Liza: noticy active cities without active ambassadors when the new application round starts

- Floris, Linda & Henri: to more research about what it means to start a foundation

- Giuseppe: put the Holland-group in the new to make 'archived groups of NL' subgroup

- people involved in reorganisation groups: find moderators for some groups

- Pieter, Jelly, Sytse & Floris: join the new member welcome group

[[Category:CS Organization Netherlands]]

Minutes 4rd Dutch Ambassasors meetup

2009-10-15T12:08:44Z

Matrixpoint:

Minutes 3rd Dutch Ambassasors meetup

2009-10-15T12:08:20Z

Matrixpoint:

Minutes 2nd Dutch Ambassasors meetup

2009-10-15T12:07:50Z

Matrixpoint:

Minutes 1st Dutch Ambassadors meetup

2009-10-15T12:07:23Z

Matrixpoint:

Dutch Ambassador Welcome kit

2009-10-15T12:06:39Z

Matrixpoint:

Inspired by the Belgian new ambs kit

==Warm welcome==

You reading this is good news! Everytime someone reads this [[Dutch Ambassador Welcome kit]] it means our active cs family is growing! From now on you’re an official cs Ambassador. In order to help you with your new tasks as an Ambassador this document contains heaps of helpful information. Here you’ll read what it entails to be an efficient cs Ambassador, how the [[Netherlands]] CS organisation works, and some tips on how to stay in the right shape! We advise to read it carefully and thoroughly.

==What it entails be a CouchSurfing ambassador==

Being an ambassador in the [[Netherlands]] should be a fun and interesting experience to be enjoyed. This document contains a the guidelines, but as most things in life it’s what you make of it yourself.

===Description===

First and foremost Ambassadors promote the values that embody the Couchsurfing Spirit. City Ambassadors are also the voice and ear to their local community, and source of information for all the members of their local community.

===Responsibilities===

Most City Ambassadors contribute at least 10 hours per month but this varies greatly from person to person. We want to make sure all Ambassadors love what they do. Please always feel free to ask for help, ask your other city ambassadors in the group or send a private mail to your country ambassador.

The '''role''' of the City Ambassadors is to be of service to CouchSurfing members and to be of service to the local community. Ambassadors are volunteers committed to helping others.

'''As travellers, hosts, surfers, and volunteers, Ambassadors strive to'''
* Promote respect and tolerance for individuals and cultures
* Promote cultural diversity and awareness
* Promote equality, inclusiveness, and friendship
* Promote honesty and fairness

'''In addition, in our role as volunteers Ambassadors strive to:'''
* Promote personal and professional integrity
* Promote the pursuit of excellence
* Promote teamwork

'''Ambassadors Code of Conduct'''
Our behaviour as travellers, guests, hosts, and volunteers is a direct reflection on CouchSurfing. Therefore Ambassadors will be held to the highest standards of personal and professional conduct. Ambassadors must agree to the [http://www.couchsurfing.com/amb_ethics.html code of conduct]

==Duties City ambassador==

There are four levels of ambassadorship: [http://www.couchsurfing.com/amb_levels.html City, Country, Global and Nomadic]. The duties of city ambassadorship is defined below. The explanations of the other [http://www.couchsurfing.com/amb_levels.html levels of ambassadorship] can be found on [http://www.couchsurfing.com/amb_levels.html the couch surfing website]. If you have any questions feel free to contact another ambassador (country or other).

It could be that your community is already active and has ambassador(s), in that case we recommend you to contact your fellow city Ambassadors and see where you can help out.
There’s a possibility that you might be the first ambassador of a city (check the [[Dutch Ambassadors ]]wiki). In that case we recommend you to contact a nearby fellow ambassador or an ambassador mentor and ask them any questions you have. They are more then willing to help you out.

===Organise local events===
Most active communities are organising meetings. This could be a set weekly meeting ([[Amsterdam]] Friday), ([[Rotterdam]] Tuesday and Saturday) or a monthly meeting ([[Utrecht]], [[Enschede]], [[Maastricht]], [[Amersfoort]] or [[Groningen]]) or just random meetings as in [[The Hague]].

There are many ways to set up a meeting. For tips and tricks check [http://www.couchsurfing.com/wiki/How_to_make_a_good_meeting how to make a good meeting page].

=== Moderator of your City group ===
A new CS city amb should become moderator of his/her city group. This does not happen automatically. You kindly need to ask the moderators of your city group to make you co-moderator. Moderators can be your fellow city Ambassadors or it can be a normal moderator who once started the group. If they don´t add you to the group or you get a negative response send a message to [http://www.couchsurfing.com/contact.html Contact Us] and explain the situation.

Your role as a moderator is firstly to provide visitors of the group a quick access to the ambassadors in your City. Secondly, City Ambassadors are responsible in keeping their local community alive, providing info and more. This includes defining group guidelines, managing/raising polls and establishing Google events calendars if required.

=== Communication ===
There are many ways to communicate with your fellow active members. The idea is to build up or keep continuing a strong local community. It might therefore be essential to keep your fellow active members involved and informed about new events, meetings and other initiatives.

=== New member welcome ===
A good way for an ambassador to welcome new members in your community is by joining the [http://www.couchsurfing.com/group.html?gid=3581 new member welcome group]. Through the [http://www.couchsurfing.com/group.html?gid=3581 new member welcome group]you’re able to find out which new members have joined your community. To warmly welcome new members and show them what is happening in your community with a welcome message can be appropriate.

Once you join the [http://www.couchsurfing.com/group.html?gid=3581 new member welcome group] you will receive extra tools on your profile to send out welcome messages.

=== Visit other local meetings ===
You’re always welcome to visit any of the local meetings. May you be looking for some new ideas, want to get to know your fellow active members, please do not hesitate to visit one of the local meetings.

=== Participate in the Netherlands CS organisation ===
Together with all the ambassadors we work on building this sustainable network, the Netherlands CS organisation. All ambassadors and active CS members who are interested are welcome to join. For more info on the Netherlands CS organisation check below.

=== Ambassador groups ===

As an ambassador you automatically become member of:
*[http://www.couchsurfing.com/group.html?gid=2125 Ambassador’s Public]
*[http://www.couchsurfing.com/group.html?gid=1668 Ambassadors Private]
*[http://www.couchsurfing.com/group.html?gid=4407 City Ambassadors (if you have become a city ambassador)]
*[http://www.couchsurfing.com/group.html?gid=4410 Nomadic Ambassadors (if you have become a Nomadic ambassador)]

Feel free to explore the topics that are discussed in these groups. A good start are the flagged posts of the Ambassador’s Public and of Ambassador’s Private groups.

=== Extra Features on CS website ===
Ambassadors get acces to some extra features on the CS website.

*First, you get an extra [http://www.couchsurfing.com/ambassadors_home.html Amb tab] in your navigation. This amb page gives all the information about ambassadorship and other ambassadors in the world and includes the groups of your community.
*Second, you can check where recent sign ups heard about CS in the [http://www.couchsurfing.com/amb_where_hear.html where did recent sign ups hear about CS?] page. You also see this feature on CS profiles in the personal info.
*Third, as an ambassador you now have extra possibilities with [http://www.couchsurfing.com/statistics.html the statistics]. As an amb you can check more specific regional statistics, per country. There is a selection box on the top of the page where you can select your country of choice (for instance, the Netherlands).
*Fourth, you can mark CS profiles as having an [http://www.couchsurfing.com/exotic_couches.html exotic couch]. When a CS member lives in a places which brings a special element to a CS experience you can mark his/her couch as [http://www.couchsurfing.com/exotic_couches.html exotic]. For instance when somebody lives in a boat or in a remote area in the nature this could be an [http://www.couchsurfing.com/exotic_couches.html exotic couch]. People who look for special CS experiences can look up these members.

Explore the features and use them for you community.

== The Netherlands CS organisation ==
The Netherlands CS organisation team meets approximately once every three months. All the minutes of the Netherlands CS organisation you can find in the in the Dutch ambassadors wiki and in the Netherlands CS organisation wiki. Please read all the meeting minutes, they contain valuable information!!

You’re automatically enrolled in this group after you have obtained your Ambassadors status. You’re more than welcome to participate in any of the upcoming meetings.

In order to collaborate efficiently and effectively, the Netherlands CS organisation uses various communication tools:
* [http://www.couchsurfing.com/group.html?gid=5031 The Netherlands CS organisation group]: Discussions, remaining in touch and exchange of ideas. New ambassadors and active CS members will be added to the list
* [http://groups.google.com/group/couchsurfingnl?hl=en The Netherlands CS google group]: All CS NL documents should be sent/posted here. New ambassadors and active CS members will be added to the list.
* The[[ Netherlands ]]wiki: It’s an open source of information and can be used and adapted even when the site is down. Feel free to add information (especially in the [[Dutch Ambassadors]]).
* [http://www.google.com/calendar/embed?src=couchsurfingnl%40gmail.com&ctz=Europe/Amsterdam The Netherlands CS google calendar]: All events happening in the Netherlands can be found in the google calender
* Datum prikker: used for setting up new meetings

=== Other Netherlands Ambassadors ===
There are Ambassadors in all regions of the Netherlands. The [[Dutch Ambassadors]] and information about the CS NL organisation meetings (minutes) can both be found in the [[Dutch Ambassadors ]]wiki. Once again, please read all the meeting minutes, they contain valuable information!!

Everyone is encouraged to be on the lookout for people that would make a great ambassador or be valuable on a working group, and encourage them to apply or join!

=== Ambassador mentor ===

As a new ambassador we understand that you might still have questions after reading the Dutch ambassador welcome kit. To help you with any questions you might still have, there are 3 ambassador mentors. We divided the country up in North, Middle and South. Each ambassador mentor is a mentor to new ambassadors in his or her region.

The regions are divided accordingly:
*North (Friesland/Groningen/Drenthe/Overijssel): [http://www.couchsurfing.com/people/gpikkio Giuseppe (GPIKKIO)]
*Middle (Noord-Holland/Zuid-Holland/Utrecht/Flevoland) [http://www.couchsurfing.com/people/lizzie82ish Liza (LIZZIE82ISH)]
*South (Zeeland/Brabant/Limburg/Gelderland): [http://www.couchsurfing.com/people/lourenssenm Maikel (LOURENSSENM)]

Feel free to contact them if you have any questions

=== Tips for meet ups & activities ===
I am sure you already have a great deal of experience in organising meetings and events. The possible fellow Ambs in your city will probably have a way of organising things. It would be good to contact them about their plans.

In the [http://www.couchsurfing.com/wiki/How_to_make_a_good_meeting how to make a good meeting page] you can find extra tips and tricks on organising meetings and events.

CS has business cards you can customize and have printed or print yourself. This is a great help while promoting CouchSurfing. Simply [http://www.couchsurfing.com/business_cards.html download a file from here] and print out on your own.

==Dealing with security issues and problem resolution procedures, etc.==

VERY IMPORTANT before posting ANYTHING linking to a member read this one: [http://www.couchsurfing.com/group_read.html?gid=1668&post=1278659 Reminder about user privacy]

Basically the approach to any problems you might have would be to either directly contact your Country Ambassador or send a message to a member of the Leadership Team using the standard [http://www.couchsurfing.com/contact.html Contact Us form].

DO NOT USE THE GROUPS!!!

Most often a member of the Contact Team will then advise you of the next steps to take or of the answer you need. Familiarise yourself with the contents of the [http://www.couchsurfing.com/contact.html Contact Us form] including familiarity with the range of items in the pull down menu labled Communication Type.

For problems (you have) with another member of CouchSurfing you can directly contact he Member Dispute Safety Team (MDST) by selecting "Problem with another member" in the [http://www.couchsurfing.com/contact.html Contact Us form].

=== Dealing with crimes such as: theft, abuse, and/or any forms of harassment. ===
What are the official procedures, whom do we contact, and in what order?
Be prepared! Read the [http://www.couchsurfing.com/tips.html Tips for Surfers and Hosts].
* If necessary contact the local police / ambulance USE YOUR COMMON SENSE!!
* If other couchsurfers are involved, contact the Safety Administrator through the [http://www.couchsurfing.com/contact.html Contact Us form]. Tell them as many details as possible about your experience. CouchSurfing will investigate and determine the best course of action. If necessary leave a negative reference.
* Dealing with Dating requests: see [http://wiki.couchsurfing.com/en/Handling_dating_requests Handling Dating Requests]

== Useful Links ==
:[[Dutch Ambassador Welcome kit]] (this Document)
: [[Dutch Ambassadors ]]wiki
: [[Netherlands ]]wiki
:[http://www.couchsurfing.com/group.html?gid=5031 The Netherlands CS organisation group]
:[http://www.couchsurfing.com/amb_levels.html The Levels of ambassadorship]
:[http://www.couchsurfing.com/group.html?gid=3581 New member welcome group]
:[http://www.couchsurfing.com/contact.html Contact Us form]
:[http://www.couchsurfing.com/wiki/Answers_to_some_common_Contact_Us_Questions Frequently Asked Questions]
:[http://groups.google.com/group/couchsurfingnl?hl=en CS NL google group]
:[http://www.google.com/calendar/embed?src=couchsurfingnl%40gmail.com&ctz=Europe/Amsterdam CS NL google calendar]

== Don’t worry be happy ==
Being an Ambassador can be a bit overwhelming. It’s really important that you have as much fun as possible. Hereby some small remarks on how to avoid stress as an ambassador:
* Do what you love. Volunteering is meant to be fun. If greeting turns you on, greet. If you love to host, host. If you enjoy taking people out and about, do that! Whatever floats your boat: every contribution counts!
* Recharge your batteries. If you start feeling drained, take a break.
* Network. Share ideas, thoughts and frustrations with other CSers you get along with.
* Portion Control. Basically, don't bite of more than you can chew. You might get a nasty case of indigestion!
* Participate. Join the discussions and make your voice heard.

= Good luck!=
We wish you all the best. We’re a team all together so if you have any questions please don’t hesitate to contact one of us. We hope to see you around! The Netherlands is smaller then you think!

[[Category:CS Organisation Netherlands]]
[[Category:Netherlands]]
[[Category:Welcome kit]]