Fediverse roadmap - what is going to change?

[mariha]

This is a container issue which aggregates all federated features in one place. It reflects my best effort (very imperfect!) to match single actionable steps with the outcome they are expected to contribute to most.

Here are the changes that we anticipate and how they map to specific GH issues:

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.

1. from communities locked in silos platforms with self-selected boards not representing communities values any more to freedom to be on a platform of their choice, with variety of platforms existing, variety of governance, variety of communities to be part of all participating in wider network of hosts and travelers

   • [ ] https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/16, to have at least two communities to federate based on Trustroots software (M)
   • [ ] https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/65 (M-XL)
   • [x] https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/66 (ex. usernames with platform prefixes) (M)
   • [x] Admins choose which instances to federate with, individual users can opt-out (whitelisted instances) (XS)

2. from few platforms without clear identity each, competing with each other for users to the bigger diversity of platforms with their own specific identity developed. Shared access to wide base of hosts and travelers would relieve the burden on platforms to fulfill all needs, and they would not fear of missing out since other needs would be covered by other platforms. One could then imagine platforms in other languages than English or dedicated to certain life choices (think of ecology or veganism)

   • [x] https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/23 (to enable self-hosting) (S)
   • [x] Easy operations and maintenance of a running instance (good observability, logging, reliability and upgrades) (M)
   • [ ] https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/24 (M)
   • [x] copyleft license (AGPL), to promote sharing - see https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/18 (XS)

3. from users jumping between multiple accounts, one for each platform to single account and one search to query all platforms and find the closest hosts among all of them

   • [x] https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/63 (L)
   • [x] https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/62 (possibly aggregated per location, no individual hosts data is shared) (M-L)
   • [ ] https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/29 (S?)
   • [ ] https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/27 (protocol what to include: location in 5km radius, username, …) (see also https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/3) (M-XL)
   • [x] https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/64 (aka matrix, ActivityPub) (M)
   • [x] https://github.com/OpenHospitalityNetwork/openHospitality.network/issues/28 (M)

4. from users from underrepresented groups (non-english speakers, women, lgbtq, …) hesitating to participate because of feeling of exclusiveness or fear of unsafe interactions to the community, where everyone feels welcome, can find their place and group where they belong to, feel safe and can fully express themselves. Full diversity of members from all sort of backgrounds and groups equally represented in the community.

   • [ ] incubate new communities (guidelines, best practices/example for governance, supporting tools) (S)
   • [ ] reach out to other communities, onboard and embrace their diverse feedback (M-L)
   • [ ] modular architecture with addons/plugins for an instance setup (L)
   • [ ] abstract protocol, welcome new platforms in the network (M)

5. from devs-maintainers competing with time to keep up to date with ever changing technologies, tired with maintaining outdated platforms, to new platforms emerging every now and then with fresh ideas, energy and tech stacks. This can be achieved by making it easy for new platforms to start based on already existing ones and evolve them freely.

   • [ ] contributors' community with inclusive dev process - C4 (ongoing process, but let's say M for instigation)
   • [ ] strong devops practices, smooth flow with good ci/cd pipeline (S), executable specification (S), etc.
   • [ ] modular/micro-service architecture - good decomposition and encapsulation to decrease complexity inside a module, separate processes (services) to be inclusive to contributors with skills from different tech stacks, yet deployed on one machine for operations simplicity (M)

6. from platforms keeping hosts forever despite them being inactive and unresponsive to only committed hosts participating in the network on their own rules and preferences.

   • [ ] user has a choice which instances to federate with (to be visible to? discoverability of instances?, whitelisted and blacklisted? instances) (S-L)

---

1. from users exchanging direct messages to indirect hosting requests

   I travel and publish: Who can host me?
   Everyone in the network can see it and someone answers: come over to my home, we’ll be waiting this evening for you.

   • the request includes everything needed to determine for who it is relevant: (a) expected location and radius (b) current location, direction and speed (c) …
   • [ ] single platform https://github.com/OpenHospitalityNetwork/fedi-trustroots/issues/30 (L)
   • [ ] federated (L-XL)