Federated Platform

[mariha]

Recent changes to WarmShowers and CouchSurfing urge to look for better ways to facilitate hospitality exchange/traveling communities. Users ended up locked in a platform where they are fully dependent on boards of directors, which they can not influence or change. Their feedback is ignored and some accounts deleted. The board makes decisions bad for the community, seem to prioritize their own profits over interests of the community.

In the survey to WS users, one person shared an interesting idea:

I want to share this idea to build a next generation federated hospex platform building on activity pub in such a way that different kind of groups/people/projects can host their own node and manage their own community (especially from/for marginalized groups, e.g. women-only, lgbtq, non-white, etc...), but the nodes could still federate if the individual instance wanted that.

I can imagine users could migrate their accounts from one instance/platform to the other with one click only, taking their contacts and history of conversations with them. They could see hosts from the other community on a map and send messages across platforms. They could keep both accounts linked together or have only one.

If moving between platforms/communities was easy, when governance in one platform was not suiting us we could simply move to some other with better rules/authorities. It would give us freedom to choose best platform for us at the moment. This will also make authorities more accountable to the community they ought to serve.

Likewise, if someone thinks they can create a better, alternative platform/community around the protocol we establish, they could enter into the space with their vision and implementation without being disadvantaged by having too few users to be considered as a viable option by other potential users/community members. This is beneficial for the hospitality exchange community as a whole.

It's natural that the "mothers" and "fathers" of the Foundation have more authority than the rest of the community members. With authority comes power. An especially difficult moment for the community is when Founders decide to step down and a successor(s) has to be chosen (as taught us WS) or even worse when they decide to stay while community wants to move on (Hospitality Club -> BeWelcome). If the power at this moment was already distributed among many sub-communities and forked instances of the platform that moment was not that threatening to the larger community.

---

The problem and possible solutions

In general, the problem could be summarized as centralized governance of community platforms.

As a solution the communities can adhere to democratic practices: board members who are selected by the community, whose cadence is time-constraint, board composition reflects diversity of the community so that everyone is represented, ... this could be guaranteed by legal status of an organization, for example [todo]. If a hospex community was built by an effort of a single person or small group of people, they usually naturally have more authority in the community and this model is not natural for them.

Some communities make legal promise that they will never become profitable, making it less attractive for harmful to the community people who could financially benefit from other members if they had enough decisive power in the organization. Seems like this guarantee may be not enough (WS).

Another option to legal measures is technology: the next generation of hospEx platform could be built in a federated way. This would allow different groups of people to run their own platform with their own rules, and really addresses the issues with these centralized platforms where the board end up with too much power. More about fediverse.

Additionally, we could (but don't have to) bake in democratic features, making it easier for the communities - instance owners - to operate in a decentralized way.

---

Requirements:

1. at least two platforms or instances of the same platform working together
2. ease to move account with its data (profile, contacts history, references/experiences/comments, ...)
3. visibility of users across platforms
4. possibility to contact users across platforms

There are two possibilities, interconnected but separate. We could do either or both of them:

1. Federated platform
   different groups/organizations would own instances of the platform, they all run the same software but operated/managed by different organizations. We'd have to be very intentional about giving possibility and facilitating self-hosting an instance.
2. Federation of platforms
   different hospEx platforms/communities cooperate so that members of one community are visible to the other, it's possible to communicate across platforms and to move account and history to other platform.

We could possibly build a federation of platforms by joint effort of TR and WTMG, maybe Couchers, Cycle Planet. All of them use Node.js on backend. Maybe also BeWelcome, they run on PHP though.

---

Implementation:

There is ActivityPub protocol, an already existing W3C standard for decentralized social networks. It is used for example by Mastodon. By implementing it we could possibly leverage some tools that built on top of it. For example:

• https://github.com/immers-space/activitypub-express
  Modular implementation of the ActivityPub decentralized social networking protocol, written for NodeJS as ExpressJS middleware. Includes a interchangable storage interface with a default MongoDB implemenation.
• clients (haven't checked)

Matrix is decentralized chat protocol built on top of XMPP, there is a platform and community of the same name that uses it. There are client applications, mobile and desktop which understand it.

There is always an option to home built a solution from the ground without looking at others aka existing standards. We could write it in a modular and abstract enough way so that other hospEx platforms could easily re-use/adapt it. Maybe over time it would emerge as a new standard.

---

Other aspects to consider:

Authority / power issues 👍

Above.

Security 👍

Trust is highly important in hospex and the instance you choose could be the thing you put your trust in. So can have instances entirely run by and for non-male persons, or any other groups.

Would also like allowlist only federation, so trust is explicit.

On the other side, harmful people could create account in one platform and the other making it harder to track them. This to prevent would require some extra coordination between communities.

Identity 👍

Many people like to express that they belong to one group and not the other. Different instances run by different entities could address that desire.

Purpose / goal / focus / other common distinctive characteristics of different platforms/communities

• Trustroots.org focuses on cultural exchange
• WelcomeToMyGarder.org focuses on free camping spots for slow-travelers

Having explicit choice people would know how the communities put different expectations on guests and hosts.

Complaxity 👎

Authoritarian/hierarchical structures are easier to understand and organize then democracies/decentralized groups, the price is freedom. Same is true for countries and smaller communities. Same is also true for centralized vs distributed software systems.

Funding 👍

The message further goes on:

I think it also could engage the enthusiasm of activity pub nerds, who would love the idea somebody would use it for something real... and possibly be more attractive to funding bodies (e.g. I know https://nlnet.nl/discovery/ are quite keen on activity pub, as a friends project (https://inventaire.io/) found out throughout his application).

https://wiki.inventaire.io/wiki/Details_about_NLNet_funding

---

NOTE: This idea was first cross-posted as an issue in Trustroots and WTMG repo.

[aschrijver]

Thanks for this great issue. It is lovely to see the plans you have in mind. Thank you too for joining SocialHub and posting about this in:

Hospitality exchange community considers moving to the fediverse

There's huge potential in this space in federated context, and it is delightful to see you intend to give this a broad approach.

Hopefully all other parties mentioned in the GH issue - TrustRoots, WelcomeToMyGarden, Couchers, and Cycle Planet - will also join you on this quest. I would greatly encourage you to invite members from all those projects to join SocialHub, as it is the best place to discuss common ground for modeling interoperability in the federated Hospitality domain.

Personally - with a background in Humane Tech Community I see Fediverse as a playground for humane technologists who want to create supportive tech that is of true value to humans and humanity. The social aspects, the people, and their communities are central to our efforts. With what we are building I see an analogy to Spiral Island. But we haven't reached our full potential yet, by a long stretch. After years of focus mostly on Microblogging, now different application & business domains are being introduced. Hospitality being the most recent example of that 😃

I'd like to point you to some topics on this forum that are relevant to think more deeply about:

• Community, community, community.. an ever-returning concept. The "Community has no Boundary" paradigm contains first steps to model this on the Fediverse.

• With Communities a given, now comes the question: How do they organize and relate to each other based on that? In What would a fediverse 'governance' body look like? we just started exploring the Governance domain, extending Community.

• What does ActivityPub et al offer us? Interoperability and integration may go well beyond separate applications and server instances. From silo-first to task-oriented federated app design explores this concept.

• Linked Data vocabulary extensions are a good fit to model your Domain. And a great methodology and process to discover Hospitality domain models is strategic Domain Driven Design. In this post in United Software Development: A New Paradigm and onwards I explain DDD concepts in context of Fedeproxy project, a different domain.

• Going beyond strategic DDD, you might apply it tactically and all the way into code and tests. The Hospitality domain seems like a good fit to do this with. DDD / CQRS / ES / Actor model / Clean architecture / BDD --> they might help to create very extensible, modular and maintainable codebases. See e.g. Event Sourcing the ActivityPub Server

In addition to openEngiadiana and Bonfire I recommend looking at @cjslep Go-Fed implemented in easy-to-learn Golang. The go-fed libraries support domain-specific AP vocabulary extensions defined as OWL, for which subsequently Go code is generated.

[aschrijver]

I just learned (via openEngiadina CPub) that Bonfire (coded in Elixir) does not use any JSON-LD / Linked Data which is a downside to take into account, should you like to adopt it.

[mariha]

I don't get (yet) exactly the difference, but what I've learnt so far:

General ActivityPub servers:

• CPub, engine behind OpenEngiadina, implemented in Elixir, uses JSON-LD over Http methods (RESTful endpoints?)
• CommonsPub, engine behind Bonfire, implemented in Elixir, stores objects in JSON blobs (I don't see an issue with this) and exposes GraphQL API (for C2S, S2S or both?, also JSON-LD can be used with GraphQL)
• Go-Fed, engine behind GoToSocial, implemented in Go
• building blocks post summarizes generic node.js ActivityPub implementations
• I might implement general AP server in Java, there are some strong arguments to that (proprietary highly scalable distributed apps run mostly on jvm, it evolved to be scalable and have well developed tools and the environment to support that, devs with distributed-systems/micro-services know-how to attract and carry the fediverse, an env that I am most familiar with)

ActivityPub URIs serve a dual role depending on the HTTP method used. Pretty much, a given URI such as the id URI of a Person or the URI of an actor’s inboxsupports two types of operations:

GET fetches an object or collection of objects.
POST receives an activity in JSON-LD format.
Note that instead of the other standard HTTP methods - PATCH, PUT, DELETE - there are different activity types (Create, Update, Delete).

(from the guide below)

Resources to start with:

• building blocks above with a list of JS implementations
• guide for new ActivityPub implementations - although we are "users" not "implementors", looking inside implementation part seems extremely valuable to build understanding what it is all about
• the semantic web in openEngiadina wiki

[lucaslcode]

Hi! I'm a couchers volunteer dev (note, this post is my personal opinions only), just came across this and I think the principles are great. I feel confident in Couchers, being open source and knowing the founders/volunteer team, but you can never go wrong with more openness.

However, I think your requirements are too ambitious. All these platforms are volunteer-run by nature and so are very limited in people-hours, and the nature of implementing a distributed system like this means it takes 10x more effort in development, not to mention organisation (getting people to agree on features, etc).

I wonder if you'd thought about instead developing some kind of distributed migration/authority system.

• hospex platforms implement an import and export function
• anyone can run this system and choose which platforms to accept
• the system connects to hospex platforms with oauth or similar, and imports profiles with all their data. It's trustable thanks to oauth (if you trust the platform)
• a different hospex provider, who has chosen to trust the people running a particular instance of this system, allows importing and trusts that the profiles have been verified
• there is still centralised trust involved, but at least anyone can run the system so it's portable.

There probably could be other approaches using cryptography and improvements with automated exporting etc.

To me, this seems much easier to implement and doesn't require hospex platforms to refactor their systems, which to be honest, they won't.

Anyway I hope it's all successful no matter what approach is taken! :)

[lucaslcode]

After reading the front page a bit more, I realize this idea probably goes against the whole point of the project, so maybe you want to disregard the comment.

I think it's important to think about how to get platforms to get on board though - it needs to be really easy imo.

[aschrijver]

Thank you for providing this feedback @lucaslcode your idea is not without merit.

There's indeed possibly a lot of work involved, but there's also prior work - many other federated apps - that we can take examples from. It is not a wholly untrodden path, though the application type is new for the Fediverse.

The topic of migrating from one platform to the other with ease is also part of the consideration in this initiative. By defining how different platforms interoperate we also necessarily need to analyse + address what they have in common and model that. This is to the benefit of import / export migration functionality as well. OAuth2 + client credentials is part of the suite of technologies that are needed.

It may not be necessary for platforms to completely refactor. The activitypub interface can be just another endpoint, like any other REST API is too. But these things need to be taken into account very carefully indeed.

Would be wonderful if you joined our Matrix chatroom and keep in the loop, to inform and correct us and maybe contribute to the project in whatever way you want! The room is at: https://matrix.to/#/#hospex:matrix.org

[mariha]

Thanks for sharing the idea! It relates to the nomadic identity https://github.com/FediHospEx/fedihospex.github.io/issues/5 that we'd like to implement.

The service that you described solve the problem of preserving reputation with trustworthy references
while moving the account.

On the other hand, it does not protect the user from vendor lock-in. It relies on platforms' good will to allow users to export their data (if I am not wrong in the EU this is a low enforced right? I asked WS for an export but never get it though). It does not either protect from the situation when the platform goes rough and deletes or misuses users data (WS, for example, censors its members and deletes accounts).

Overall, I think it would be a good step towards full implementation of a nomadic identity.

I was thinking we could take baby steps, and do something like:

1. start with plain import/export, no authority involved, user could change their references as they wish to, still it's a convenience to be able to move profile, contacts maybe messages.

2. Next phase could be what you described. The data can be migrated while remaining authentic but it is still under the control of a particular platform.

3. And the last one, based on solidproject.org. A user owns and controls its data and authorizes which platform can access it. A federated platform would not store data locally but instead in that remote storage. User could authorize other platform to read it when they wanted to migrate and cut access to it for mistrusted platform. The data could be signed with public/private keys to ensure authenticity. No authority is involved and the architecture is fully decentralized.

This is just an idea. There are probably other ways this could be solved, haven't looked much into that (yet).

---

For the feasibility part:

1. we plan to start with whitelabeling Trustroots and adapting it for homeless bicycle touring community and the backend potentially also for WelcomeToMyGarden.

2. then, we'd like to add some federated features so that the three communities can communicate across boundaries.

3. If it goes well we can abstract a protocol that will allow other platforms/communities participate in the federation, to the extent they choose to.

4. For the new communities we could make it easy for them to customize, run and own their own instance, either by providing managed hosting option or self-hosting.

You are right, it's a lot of work. We don't promise anything but if everything was working well for us we'll just keep going and at some point maybe we'll get there (or to some other place).

You are very welcome to help! To