P2P hospitality

From Sharewiki.org
Revision as of 06:10, 30 August 2017 by Traumschule (talk | contribs) (Category:Hospitality)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

P2P hospitality is a hospitality exchange that goes from one person to another. Often this exchange is organised through hospitality exchange networks. Sometimes it also happens sponteneously when a traveler meets someone at a bar or on the road. And a third way hospitality exchange happens is by friends offering their friends contacts.

Is there a way by which we could combine these different formats? Are there ways to have hospitality exchange organised more efficient, that it works best for both hosts and travelers? And how could we organise something that is distributed and not centralised, ie. genuinely p2p?

Problem-definition

With the ever increasing popularity of hospitality exchange based real social networks, travelers also face more and more the trouble it takes to find the right host, or even a host. The system as it is require you to go through many profiles, write personalised e-mails, and it also is important to have many existing friends and references in your profile.

Many online hospitality exchange networks exist today, many more than five years ago, including some based on lifestyle. However these don't solve the main problem, and they are just a copy of the other. The only real differences are popularity and usability.

More and more travelers though decide to stop using these platforms, for example because they don't want to spend so much time at the internet, browsing through profiles all the time. But also it is hard for them to connect to the right people, and to find hosts. They often just write to friends they have to ask if they know anyone in a particular city or place. For one reason because, it is often easier to stay with them, and for another reason, it saves you a lot of time. What recipes can change this, and make use of both systems?

Interest based connections

A simple way of solving this is that for each query that a user makes, the results should be more according to people they could connect with well. This could be achieved through tag-clouds in profiles. People could search for hosts based on possible connections between them, such as dumpster diving, tango and lego-fanatics.

Problems with tag-clouds

  • Multiple languages
  • Free tagging vs Fixed words
  • Categories

Trip-planner and See who's coming

Another much debated solution is that hosts would be able to see who is coming to their direction. As a traveler you fill in details about the trip you're making, and hosts could contact the travelers they like. In combination with the interests-based connections, the query would give a result in that order. Triggers could even send out notifications if a traveler with specific interests comes nearby, and travelers should be able to update their trip-plan by multi-channel (sms, e-mail, update status, identi.ca, etc.).

Friend based connections

Another step is to have results of a search based on existing friend-connections. Someone in city B is already connected with a friend you met and therefore this person will appear higher in the results, with the level of friend connection clearly visible.

A new experiment?

Imagine building up hospitality exchange networks with the knowledge we have today, from scratch? With the ideas we have now. How would you do that?

The following is a proposal that sounds complicated but is in fact very easy. It is not based on a social network website, not on profiles and not on popularity rating, friend-links and references. Rather it is a simple database with many available hosts that are only available to a user, if they have bene granted permission. It is based on a friend who gives another friend their contact details of a place/ house where they could possibly stay for some time.

We start with 10 to 50 people, invitation only. These people fill in a form with information on friends they have, all over the world. These are friends that could be potential hosts. For each person on that list you give access to be viewed by your friends. A query to the database, for example by e-mail or through a simple webpage interface, would give you the results of hosts that your friends selected for you.

Levels of Trust and so

However, for various reasons, there are hosts in a personal database that the person does not want to share with everyone but just with a few selected friends. But those selected friends are allowed to see the full contact details for example.

This can be accomplished either by a tickbox in a very simple database overview, or through giving different degrees of trust to different friends. A list-pull for one friend would generate different results than for another friend, without them having to notice it.

Database information

  • Level of commitment
  • Contact details
  • Friend-connection
  • Comments about them

Database entries could be uploaded through a simple sheet with relevant information filled in the fields, or one by one through a simple webform. Also, exporting and important friends from existing social networks should be possible.

Sleeping profiles

There are two types of users in this system. The ones who actively take part in it, and the ones who are willing to be a host (for the selected friends only, for all friends, or even for everyone). Someone who is a willing host, can activate their profile and add their database entries.

Active profiles

The active profiles wouldn't have much information on them. This is not necessary. Trust goes through the friend-links, and people would have to write the information about themselves in their e-mail or could just forward their potential hosts to a profile they have elsewhere, or to their website, etc. Exactly how things are done right now, when we are e-mailing a friend of a friend.

Notifications

When the information about people is being uploaded, they should get a notification e-mail from the person who provides their information. A template e-mail could do the trick that the user can edit before sending it. The person should be explained what this system is about, and how they can opt-out for example (or the other way around).

In this e-mail would also be stated how many friends could see their info and what type of info, as well as information on how to also have an active profile.

Commitment

This system requires each user to update their personal information about their friends on a regular basis. Entries would also be giving information on when was the last time this information was updated.

Another option is that people who are within the database get an e-mail once every so often to ask if they can update their information, if applicable.

Cons

  • It looks complicated, and it is not easy to explain
  • It requires commitment from the people involved
  • It might be hard to explain to your friend why they are in this system
  • Someone needs to build this database :)

Keep it Simple

The whole idea of this system is to keep it simple (KIS), while at the same time making it highly advanced. Starting with a small database and just see where it would bring us, might be the best idea.