I outlined the reasons in my into post Hello from hospitality exchange community devs!
The idea is drafted here: https://github.com/mariha/federated-trustroots/discussions/3
I’d like to discuss the idea and possibly get some help in the direction where to go next. In particular, I am not sure if ActivityPub is what we should use to implement our federation. We are not social media platforms.
(Photo by Tim Douglas from Pexels)
Welcome @mariha!
I am thrilled to see your community wants to embrace ActivityPub to revive grassroots hospitality networks that were captured by the capitalist mindset of “value extraction by dispossession”. Indeed, WarmShowers and CouchSurfing among others were created by the people for the people, as commons-based cooperative networks. It’s important that new and old grassroots initiatives take the time to reflect on their collective technological practices and choose to embrace a commons approach to decentralized welfare technology production that support inherent technological sovereignty and favors governance for and by those who actually create the common pool resources.
Although the first generation of ActivityPub-based software for the most part replicated existing centralized social media, there’s a lot changing in the community especially with regard to figuring out ways to provide useful services without replicating deceptive patterns leading to a capture of attention.
Hospitality networking seems very well suited to create opt-in, volunteer-based, commons-oriented ways to connect bikers and showers, sleepers and hosters, and sound to me very much like actual social networks, if not social media in the primitive sense of self-promoting media and sharing cat pictures. If a digital technology can ethically enhance sociality, then it must be a social media.
In order to avoid yet another capture of your network’s value, it’s important to disperse power and decentralization around geographical zones. This can help both providing a global network and strengthen solidarity hospitality networks locally thanks to making people pooling (technical) resources together where it makes most sense: the closest possible of the resource. Commons governance has been studied for more than 50 years, and adequate rules to create and maintain successful institutional arrangements have been known for 30 years, notably thanks to the work of Elinor Ostrom. I would encourage your communities to explore how Ostrom rules for the governance of the Commons can be best put into practice to bootstrap what you need. The #fediversity category is probably the best place here to work with technicians and fedizens around such intersections between software development and social science.
One of the important aspects of your endeavor would be to insist on providing free software under a strong copyleft license, as it has been the case for most ActivityPub #software implementations so far (AGPL): ensuring that code remains in the Commons, and is not captured by private interests that will definitely end up destroying the spirit of hospitality.
I would expect #software:openengiadina and #software:bonfire to be good candidates to start with since they both cover local knowledge and communities. I hope we can see your project mature around these premises!
Like @how I am equally thrilled. 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.
Can affirm that. 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.
As @how well describes 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 post United Software Development: A new paradigm? - #9 by aschrijver 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 @cjs #software: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. I intend to use these myself for my - yet to be publicly announced - Groundwork project (but spending most spare time still on fedi advocacy 
)
(PS. I will copy most of this message to the Github issue for reference)
Note that a bunch of these threads are long reads with all the comments on them. For both Community and Governance domains we should really start full-blown projects to elaborate on standardization of formats, etc.
Hey @how,
Thanks for your comment and warm welcome!
Well said! I still need to learn about ActivityPub to better understand how fits into what we plan to do. I wasn’t concerned that much with attention-catching aspects of social media it’s more that we don’t publish any content. There is fixed location to be shared, fixed self-made description and reputation (trustworthiness) built over time by having interactions with others, sometimes 1-to-1 messages are exchanged. Would be nice to be able to preserve them while having freedom to move. Also maybe history of messages and contacts.
I’d have to read more about Elinor Ostrom and her rules for the governance, thanks for pointing it out to me.
I have in mind a few other projects that I wanted to do, which fall in this category very well too. Hospitality exchange is more out of necessity of the moment. The others were (1) gear sharing (renting) for slow-travellers/human-powered vehicles (my favourite one, which I hope I can make living of), like bicycles and bike trailers, skis, kayaks and (2) a platform facilitating toys/cloths/baby gear sharing (giving away, lending, selling) and then (3) tools sharing like saw, hummer, and more specialized. (1) and (3) have a common piece that are quite expensive and too infrequently used to buy and just own. (2) is what already happens it’s just a matter of facilitating it and this way promoting production of long-lasting things. Sports equipment (1) in addition to that is hard to transport and very local to the place where it can be used which is often different then the place where people who would like to use it live. I’d be happy to share here my updates on them!
Thanks for pointing me to #software:openengiadina and #software:bonfire, both look very interesting and relevant!
AGPL is how I was planning to license my other projects ;). For the federated hospitality exchange platform we have two choices how to proceed:
Implement it as a library, like a communication mechanism external to the already existing platforms, that would be reused by each platform, with some custom connectors. I think it can be licensed with AGPL.
Start with one of the platforms and implement features of interest with one of the others, this is what Trustroots team suggested, that we don’t need ActivityPub but rather dig down into how the projects were built and add cross-authentication, import/export of data, aggregated by region visibility of users (that there are 3 users in the area) rather then exposing individual users etc. I guess then we could make it more abstract and extract it to the separate being or not, as we see the need.
Start with Trustroots codebase and federate it with itself only at first and then extract abstracted code into the library and integrate with other platforms, one by one.
From the existing platforms/communities, which more-or-less enthusiastically expressed interest to federate:
All of the above are written in JavaScript, what makes integrating them way much easier
Do you think any changes to how the projects are licensed would be needed/desired before they can federate?
Thanks again for taking the time to read and answer me!
Thanks, there is indeed a lot to read and learn! If only the day had more than 24h and my daughter slept most of that time 
Human Tech Community seems very interesting, even though my relationship with humanity is a difficult one. I’ve been focusing mostly on minimizing human impact on the rest of the nature most recently… but I do recognize that I can’t do it alone, after all.
I’d ask guys to join SocialHub, we’ve been discussing in communities’ Slacks so far and missing a common discussion channel.
[to be continued]
I can strongly recommend using Matrix for chat environment. Slack is proprietary and not well-loved on the fediverse, and Matrix, decentralized, has many different chatrooms to join with topics related to federation. It is the ‘community extension’ for chat, imho.
Thanks for @mariha for coherently expressing this idea 
(me having written some rambles to her about this idea too). And @aschrijver and @how for their validating enthusiasm 
.
(I wrote about my background in my welcome post).
I would like to support this initiative in a low-key kind of way, and have been chatting with @mariha about it more informally too. Maybe if a few people wave around enough enthusiasm at some point some code arrives!
I’ll (ab)use the apparant tolerance for long wordy posts here, with my own long wordy post!
Governance has been a challenging and fascinating topic for me in all the grassroots community software projects I’ve worked on, and I’ve come to see the value of autonomous independent nodes, organising as they wish, but able to opt in (and out) of bigger wholes as desired.
In https://karrot.world we approach this by each group on the platform being independent rather than by tech-based federation (as most of the groups would not be able to run an instance), but would potentially like to do that too later.
For me personally, the fediverse (by which I mostly mean mastodon) is really working (an “alternative” platform that is not entirely full of discussions about the platform itself ) - and I love the properties of:
For hospex these things seem potentially very exciting .
Mastodon allows 100s (1000s?) of communities to exist independently yet speak to each other, I’d love to see 100s or 1000s of hospex platforms that can cater to peoples needs more independently, yet still allow cross-communication. Safety is huge topic in hospex as peoples physically safety is really on the line - I’d love people to be able to choose their community of trust and federation options to meet their own definitions of safety.
There is still a very tricky centralization problem of the governance of the protocols and the development of each tech platform (developers not generally representing or understanding the needs of the communities very well), and for that I really enjoy things like the design justice principles.
I don’t know so much about activity pub, but the challenge to me seems how to express the activities of hospex in the language of activity pub / activity streams / etc. Most thoughts about how it should work will encode or embed various cultural/value assumptions, so seems wise to make these explicit.
A few examples:
My personal hospex cultural preferences are for a kind of spontaneous / short term (0-24 hours) messaging-based communication within a small community of very aligned people, for brief stays as I travel. Others seem to enjoy participating in an online “travel community” (tips and stuff) first, planning in advance, doing local cultural activities together… and other stuff I probably have no idea about.
I generally like the principle to make things (at least) one level more abstract than the underlying activity, to allow scope for appropriation of the tool for uses the designers did not know about (considering how much is possible with general chat/facebook groups alone, there is quite some scope there!).
I’m curious if there is any tooling for building activity pub ontologies, or whatever, to help express possibilities? Although I most highly value chat (voice/video) in addition to written “backup”, and more concrete exploration, shortly followed by working code 
I’m not sure how much capacity I have to contribute to this practically though - I do quite enjoy the position of bridging abstract conceptual blahblahblah-ing into what might be needed for code to appear, which is sometimes more human, sometimes more technical.
Anyway that’s (more than) enough from me for now!
Hey, sorry for being late to the thread. I’ll admit i didn’t have the chance to fully grok everything, but was connected to this particular bullet point from @aschrijver . I hope my butt-in isn’t viewed as a derail.
There is the concrete option of using go-fed for this. Go-fed is a suite of libraries that implements ActivityPub in a ontology-friendly way in Golang. </elevator pitch>
What that means concretely is, one could:
astool to code generate the ActivityStreams implementation in golangactivity or apcore libraries, or GoToSocial (I’m unaffiliated with that project) to rapidly prototype federating with that ontology via ActivityPub.I’m happy to dive into more detail, but just wanted to provide a concrete engineering option.
I create a Lemmy post related to this topic:
(@mariha I added a picture to your first post, so that that displays when sharing the link… hope you don’t mind. If you do, then I’ll reverse)
Update: Announced the Lemmy post in: Humane Tech Now: "Since a number of great project in the Hospitalit…" - Mastodon
this is awesome, thanks @aschrijver!
FYI, for instant messaging (coordination) we use:
Both rooms are mirrored. You are more then welcome to join!
Great that you come up here @mariha
From your links I realize there are indeed more platforms then what I imagined, and none have a clear identity so I can imagine the conversations between users idefinitely explaining why they prefer this or that platform.
Indeed federating would certainly help this bringing access to all information relieves the burden on any platform to fulfill all needs, I imagine it would diminish the competion between platforms.
In consequence the different platforms could develop their specific identity , 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).
I can imagine AP could help a lot regarding safety issues as users could share their profile accross different AP platforms therefore they become more accountable as they would not want to harm their reputation on other social media if they abuse a couch surfing situation.
Same thing here, relation to humanity and to humanism as a historical universalism is very difficult, but indeed this is a side note.
Hi @natacha!
BeVolunteer, an organization behind BeWelcome gives an interesting historical context of how hospex landscape was (r)evolving. Except a few (Servas, CouchSurfing, WarmShowers, WelcomeToMyGarden?), looks like new platforms were basically built because of disagreements of how the old ones were governed (Servas ->? Hospitality Club, HC → BeWelcome, BW+CS → TrustRoots, CS → Couchers, WS → CyclePlanet), not because they had any distinctive identity aspects in mind.
I hope this is the future we are heading to 
Thanks for outlining it, very well said!
That sounds like a plan, that we need to bring to every problem 
Interesting to read https://www.bevolunteer.org/about-bevolunteer/history/ this is a common history to alt-groups/projects in part it’s the #geekproblem in part something every left wing project has to work to overcome.
Thinking #activitypub is a good fix as it mediates the “diversity of tactics” that is core to the spiky/fluff debate that I touch on here http://hamishcampbell.com/2021/05/28/we-live-in-a-world-full-of-monsters-dressed-in-fluffy-clothes/
Worth a look at this one on the same subject http://hamishcampbell.com/2021/05/08/there-are-circals-in-protest-and-most-alternative-grassroots-movements/
3 posts were merged into an existing topic: Proposal: New top-level forum section for Domains
One topic I’m curious about is security/privacy and safety needs.
On the twitter-like part of the fediverse, the feeling seems you would only really trust it for semi-public discussion. The privacy controls are not intended to be hard safety barriers, but best-effort. At least from a user perspective it seems wise to treat it in this way, and use other platforms where secure communication is needed.
But for hospitality exchange this aspect is a bit different. A few thoughts:
(by node, I mean an instance of some hospex-like activitypub server)
I don’t really know how this stuff is handled in the fediverse, but I think the way it works out on mastodon et al. is not sufficient for hospex safety needs. In all cases, I believe the users really need to be able to give their truly informed consent regarding their own safety needs.
@nicksellen it might be interesting to look into what @darius is doing with Friend Camp and Hometown, mentioned in Standardizing on a common Community domain as AP extension? - #22 by aschrijver
One thing that Hometown provides is Local-Only Posting:
Mastodon right now is designed to get your messages out to the entire fediverse. This is great, but there is a huge need for more private communities. And in a federated network I think it makes the most sense for your home server to be that community (hence “Hometown”).
Another new federated app under development, GoToSocial (based on #software:go-fed) is having local-only posting on the wishlist. Interestingly GoToSocial is headless (no frontend, API-only) which lends itself well to tailor custom UI’s on top. The developer is in the Go-Fed Matrix Chatroom.
Local only (infrastructure-wise) posting is an interesting idea. I guess this way we could handle one-on-one message exchange within a local community as well as broader discussions in the community (afaik none of the hospex platforms has it right now, WS has external forum and TR has something similar for circles on the roadmap).
Other interesting idea that we discussed with @nicksellen elsewhere would be local only posting in geographical sense. This would allow to make indirect hosting requests, something like:
I am arriving to the city and I broadcast a message: Who can host me?
Everyone in the area can see it and someone answers: Come over to my home, we’ll be waiting this evening for you!
without any upfront planning and commitments.
That would be great! There is a lot of uncertainty when traveling by bike, I hardly ever plan ahead of time, I think only when I have to make to the airport/train station to go back home and I consider it hard inconvenience. Out of 3 weeks trip half is pure pleasure of going anywhere I want and second half or at least 1/3 feels like rushing to get back at time.
Maybe that’s also why I hardly ever used WS as a guest. And most people who stayed with me were either starting or finishing their trips (my home was in a 1-2 hours ride from the airport in both places where I hosted)
@cjs thanks for writing this! I looked at your projects quickly and it seems very useful, and very well thought! Sorry for not answering earlier. I think I just need to understand the ActivityPub and ActivityStream themselves better before jumping into implementations, would be happy to chat with you later when I have some concrete questions, but go-fed and goToSocial are definitely worth considering, as a prototype and going forward.
Otherwise I considered either (a) ActivityPub-express, a JavaScript implementation of AP as most of the platforms are written in JS and to start by federating two instances of Trustroots with each other or (b) to just organically add feature by feature:
to the Trustroots - BeWelcome federation (what tech leads from both communities thought was worth doing anyways).
Do you already have similar functionality in current platform, that are based on geographic location? In ActivityStreams you have the as:Place object that allows specifying coordinates, usable maybe for filtering, and one might have some address-related fields attached to their as:Person or as:Profile (maybe using vcard:Address which is recommended for such extension). I don’t know if / how other federated apps have support similar information.