Hospitality exchange community considers moving to the fediverse ;)

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 :stuck_out_tongue_closed_eyes: )

(PS. I will copy most of this message to the Github issue for reference)

1 Like

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!

Licensing

AGPL is how I was planning to license my other projects ;). For the federated hospitality exchange platform we have two choices how to proceed:

  1. 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.

  2. 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.

  3. 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

  • BeWelcome.org GPLv2, it’s not JavaScript but they also expressed some interest in federating, as long as we overcome data protection concerns

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!

2 Likes

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 :wink:

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]

1 Like

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.

2 Likes

Thanks for @mariha for coherently expressing this idea :+1: (me having written some rambles to her about this idea too). And @aschrijver and @how for their validating enthusiasm :grinning_face_with_smiling_eyes:.

(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!

Background context pondering

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 :wink: ) - and I love the properties of:

  • can share software platform (e.g. mastodon) (as software is hard to develop)
  • can run instances independently with own governance mechanisms
  • can opt-in/out of federation with other instances
  • can interoperate with other software too (client+server)

For hospex these things seem potentially very exciting .

  1. the challenges of building software platforms - each new hospex community puts together an exciting new shiny tech platform, only to struggle some years later when it’s not cool tech any more, and the kind of work required has become a chore, leaving burnt out grumpy developers left and a pile of tech debt, … or commercial sell out of the community (who are the people that actually made the platform useful).
  2. critical mass issues - each hospex platform struggles to get enough people to join, and people get tired of having too many accounts on too many platforms that have too few other people on, federation can solve some of this
  3. community self-governance - with only a handful of platforms available to choose from, the governance of those is usually left to the usual type, who already hold some kind of power in society, building tools that allow groups of people to govern themselves addresses some of that

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.

(Slightly) more concrete stuff

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:

  • hosting requests with arrival/departure dates (like airbnb), encodes a transactional consumerist perspective that communities that value connection might want to avoid
  • trip itineraries (like couchsurfing) presupposes a planned kind of travel, whereas some communities would emphasis more spontaneous travel
  • review/reference features (like many things) have their own complex set of dynamics… (reluctance to leave negative reviews)

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 :computer:

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!

1 Like

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:

  1. Write an OWL file of a new ActivityStreams based ontology (ForgeFed ex)
  2. Use the go-fed astool to code generate the ActivityStreams implementation in golang
  3. Use the activity 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.

5 Likes

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

1 Like

this is awesome, thanks @aschrijver!

FYI, for instant messaging (coordination) we use:

Both rooms are mirrored. You are more then welcome to join!

1 Like

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.

2 Likes

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 :green_heart: Thanks for outlining it, very well said!

3 Likes

That sounds like a plan, that we need to bring to every problem :slight_smile:

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:

  1. messages sent within a node should never have a way to leave that node
  2. the safety-team on a given node might need access to the messages (hospex safety issues can be serious, involve the law, and be physical in nature)
  3. in practise, the server admin will probably always be able to read all messages, and the users should hopefully feel comfortable to trust the node operators
  4. malicious/hostile nodes should not be able to fake anything… personally I’m into allowlist-only federation to maximise trust, even if it means slower network growth, and nodes should be authenticated somehow

(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:

  1. cross-platform-authentication,
  2. import/export of data,
  3. clustered users from the other platform visible on a map

to the Trustroots - BeWelcome federation (what tech leads from both communities thought was worth doing anyways).

1 Like

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.

We don’t have yet, it would be very nice though.

In FB groups for WS and some other travelers related and even the one that I moderate for Open alternative to WS people ask this questions every now and then. It’s rather annoying because it’s irrelevant to 99.9% of people (120K members for example) and the chances to find anyone, who lives in a bike-driving distance and is part of the group and is online and willing to host are pretty low I’d say.

1 Like

This is such a fascinating effort and I’m glad to be here as it’s getting started, with so much feedback coming from the SocialHub community. A lot of links have been provided which should make for some good reading.

On the technical side of AP-enablement, I see tremendous value in two approaches.

  1. Delegating everything AP-specific to an external tool. GoFed is mentioned and ontologies which is frankly awesome. Potentially another hidden gem of the fediverse.
  2. For any systems that wish to implement AP, to try to do so as a plugin. The nice thing about plugins is they let core developers stay focused while instances can diversify and test out features more easily.

As an aside: On the point of local-only posts, is it not possible to leave that to each project? Certainly a project can have some internal flags on their objects that say, “don’t send this over the AP wire,” so it’s never becomes an AP concern.

-David

2 Likes