A Roadmap to Federated Hospex

[mariha]

This is a container issue which aggregates other issues into a linear roadmap, created for the need of NLNet founding. You can find more details in our trello board.

Where we want to get

We want a variety of hospex communities/platforms that are able to communicate with each other. This includes:

• existent platforms: Trustroots, BeWelcome, WelcomeToMyGarden, ...;
• communities without a platform: bicycle touring community (formerly Warmshowers.bike), Host a Sister (fb), ... ; or
• new communities yet to form.

For communities without platform and new communities we might offer a way for them to have a platform (on their own, or hosted by us).

What does it mean for platforms to communicate with each other?

1. Members of one community can see hosts of other community (e.g. on a map).
2. Hosts of one community can see nearby hosting requests from travellers of other communities.
3. Members of different communities can send messages to each other.
4. Members of different communities can see profiles of each other. (nice to have)

Awesome future dreams

• A mutual aid community of people helping each other on the road beyond hosting
  e.g. a cyclist can share that they have a flat tire or their bike was stolen and ask for help
• Find a travel buddy/companion
  • destination related
  • no matter where, but with who!
• Data ownership - user owns their data, data is stored independently from the platform (Solid)
• Address ownership - user owns their address (unique id) as opposed to user@host schema where user's address is linked to the platform (ex. nostr or zot protocol)

How do we want to facilitate the new and existing communities to be part of the network?

1. Technical infrastructure to set up a new community in an easy way
   • easy way to rebrand for the needs of the new community
   • easy way to deploy an instance
   • (facilitate exchange of howto/best practices for starting a new community, attracting members, moderating, ... - forum?, knowledge base (wiki)?)
2. Technical infrastructure to connect an existing community to the rest of the federated network
   • a JavaScript (TypeScript) library to encapsulate communication layer
   • an abstracted protocol of communication, so platforms can implement their own communication channels in other languages ((ActivityPub, a way to fetch data from each other))

How will we get there?

Estimate definitions

Each item has a rough effort/complexity estimate: (XS) - S - M - L - (XL). The estimate represents my perception of them not an objective measure. With bigger complexity comes greater uncertainty.

XS <<<< M - much less then M but worth noting down because of it's importance
S < M - less then M, still quite an effot
M - point of referance // around 1 month of full time work
L > M - more then M
XL >>>> M - really too big to reasonate about, should be split

Steps to make

(Items/estimates in bold are those which I asked NlNet for funding, to be included in Memorandum of Understanding)

1. have development process with a forked repo, in a way that minimizes merge conflicts and maintenance (S)

   • < (e.g. mutual interest/understanding on working together on a shared codebase) >
     • ? what is common/shared and what not? (codewise) What is merged back to TR?
   • relicensing/new copyleft license in TR to be able to reintegrate changes back from fedi-tr (XS)
   • process to keep fedi-tr in synch with tr with linear git history (no merge commits)

2. deploy fedi-trustroots as sleepy.bike, so that people can sign up (XL)

   • deploy fedi-trustroots to sleepy.bike (S)
     • DevOps - set up separate servers, databases, email, domains, cd pipeline
   • rebrand: new logo, front page, colors, ... for sleepy.bike (S)
   • make the codebase generic and easily rebrandable (e.g. via a (json, yaml) config) (M)
   • (?) hide (behind toggles) non-essential, trustroots specific functionalities (XS)
     • essential for a distributed hospex platform:
       • [traveller] search for hosts (map or other)
       • [host] publish a hosting offer
       • [community member] account: user, password, email
       • todo: [other communities] search a host
       • todo: [other communities] trust management
     • non-essential:
       • [community member] personal profile
       • [community member] references
       • [community member] connections (find people, connect)
       • [community member] messaging
       • [host] search for traveller
       • circles
       • meetups
   • broadcast info about the new platform / invite everyone to join

3. have two platforms running that use the ohn protocol (S)

   • fedi-trustroots as sleepy.bike should already be there
   • trustroots - facilitate them to join the network
     • merge changes back from fedi-trustroots
   • fedi-trustroots as fairtravellers.world if not trustroots
   • (?) new sleepy.bike as a minimalistic app in TypeScript using the protocol

4. create and implement hospex protocol for a feature

   • users share their hosting offers (XXL)
     • hosting offers from other platforms are shared via ActivityPub and stored locally and displayed on a map as a "circle" (L)
       • ActivityPub infrastructure design & setup, hospex ontology design
       • publish and receive hosting offer "event", store in db, display
     • profiles from other platforms are discoverable and can be fetched and displayed locally on a request (functional profile, via OAuth or other authentication protocol) (M)
     • trust between platforms: config with other communities that are connected and default trust for the community, to be overwritten by user preferences in the gui+mongoDB (L)
   • users share travel plans (public hosting requests) (L-XL)
     • a board with hosting requests in the area of a host
       • create a request
       • all requests in the community are presented to each member
       • (optional) geographically relevant requests only
       • requests from other communities are displayed
     • pieces to do: protocol; implement backend; UI, UX design; implement frontend
   • users send messages to each other (M)
     • messages can be sent between platforms via ActivityPub, and e.g. stored locally by each platform
   • [in the future] mutual aid - expressing needs to people nearby (underdefined scope)
     • the same board as hosting requests may include other needs of travellers (e.g. the flat tire example)

5. create and publish a library for connecting to the federated hospex (TypeScript implementation of the OHN protocol) (M-L)

   • extract code from fedi-trustroots to a separate library (S)
   • describe the protocol (documentation for other implementors) (S)
   • nice to have: write test suite to ensure protocol compatibility (M)

6. facilitate new and existing communities to join the Network (one community from a category + a guidebook for others to follow):

   • with own platform: help them integrate hospex federation libraries to their codebase (BeWelcome, WTMG)
     • platform code written in Javascript/Typescript (e.g. WelcomeToMyGarden, CyclePlanet, (Trustroost, if not already involved)) - to use our implementation of the protocol (L)
     • platform code written in other languages (e.g. PHP) (e.g. BeWelcome) (XL)
   • to onboard on our platform (currently on Facebook, outdated codebase, e.g. HostASister) (the same as starting a new community + migrate existing members to this platform) (M)
   • starting a new community (support the community to deploy an instance, rebrand, invite members, establish trust with other communities) (M)
     • document the process into a guidebook

7. solid

   • as an independent platform(s), connected to the rest of the network via the OHN protocol, ex. sleepy.bike
   • in fedi-trustroots, as an option for data storage independently managed from the platform admins