I must say, it’s really something to hear about all of these projects a few weeks into my exploration of the fediverse. I’m taking it as a signal that discoverability is a challenge that needs help. Your page listing instances of so many AP and other projects is really good. Fediverse.party is really good. And I hope to be able to raise some attention on the question… when you venture off of mainstream social media what’s the best way to get to know your options. Feels similar to what I imagine an expat has to contend with. How many nations could they have visited and for how long? Or is the pull really social, as in following who you know?
I’m taking it as a signal that discoverability is a challenge that needs help.
Not really. We stay mostly under the radar because that is our choice.
Concerning discoverability I think that the fediverse already established some mechanisms. Most projects support the nodeinfo protocol. Also many systems provide API endpoints where they publish their known servers they are peering with. And last but not least, in AP the contacts can publish a list of their followers and followings.
In Friendica we are using this data for example for suggestions whom to follow.
What I like about the fediverse is that the different software projects and users can decide on their own if they want to be part of this discovery. Users can set a flag if they want to be searchable. In Friendica users can also not only chose if they want to publish their contacts but even when they do so, they can exclude some contacts from these lists if they want to.
@heluecht I believe @weex was probably referring more to discovery of what the 70-80 (?) currently known ActivityPub platforms offer and what kind of target audience would best be served by each platform.
There have been a number of attempts at independent discovery services such as fediverse.party and the former switching.social. The issue I’ve found with these is that they are heavily biased to the publisher’s personal preferences and they spend maybe 30 seconds looking at a project. Many of the reviews and descriptions are not well informed and are usually wildly inaccurate and quickly outdated.
You may have noticed that whenever a fediverse platform shows up on hackernews, 60+% of the comments are along the lines of “they’ll never succeed. Where’s the business model?”. Most of the remainder complain about the “marketing” and “branding” because these are the only concepts the commenters believe in - it’s all about unlimited growth and making billions of dollars and brand names. Then there are 3-4 comments from actual fediverse users or developers trying to explain that these not only aren’t a priority, they are all merely facets of the multi-headed dragon called corporate capitalism and world domination we are determined to move beyond before it kills us as a species.
As I quote often from the former CEO of Netscape -
“The outcome of a battle between a bear and an alligator depends on the terrain.”
I’ve also said this before, but I think the best solution for this is for a website of some kind providing an open discovery process where people can engage with others who have actually used the software on a daily basis and provide open reviews and relevant commentary. Preferably using a fediverse-based platform so they don’t need to register on the review site to participate. I would build it myself tomorrow if it weren’t for the obvious conflict of interest. Any volunteers?
Well said. As a developer it’s tempting to think here’s a funnel (I know what to do with funnels!) but as a user I went off of stories I had seen, what I currently use, and picked one platform to try. A year later, here I’m digging deeper with a desire to suss out what kind of social networking, if any is good for my humanity.
I don’t want to be driven by likes. I want to have deeper conversations vs gotchas and dunks. I feel that video and audio conversations are superior to text for connection so wondering about how those might be integrated. At a high level, I see loads of features and loads of networks and that the mainstream players all evolved with the dollar at the helm.
Putting my developer hat back on, I’m now looking for a platform to build on and it’s that old problem: the longer a project has taken, the even-longer it will take on average. That’s how I feel about finding platforms to evaluate as a base. It’s a good problem to have though… I shall get back to it.
Very broadly speaking, there are four major categories of AP projects.
- Twitter-like (“microblog”)
- Facebook-like (“conversational” with groups, events, and media management)
- Dedicated-purpose (pixelfed, peertube, funkwhale, etc.)
- libraries and plugins (“tools”)
Within the categories, there’s a lot of variation. But a good place to start is to at least figure out which of these is closest to your requirements and that narrows the field substantially. The fediverse is dominated by #1 and to some extent #3. My own software falls firmly into #2. The first two realms are not completely compatible. At best we co-exist in the same space and can interact with each other in a basic sense, but they are very different worlds attracting very different people and usage patterns and expectations.
I am co-maintainer of the wiki watchlists that are input Fediverse Party. These watchlist have the inclusion criteria that even the intent to build an AP federated app is enough. And if that project is no longer maintained, we’ll keep it on the list still because the code may still be worth a peek by other fediverse developers. Entries are input to the Fediverse Party website itself, that is maintained by one volunteer - @light - who can only spend so much time on it and is aware that for a general audience a different setup is needed.
List maintenance is time-consuming, and a boring chore, but someone has to do it Nonetheless the AP apps watchlist is the most complete you’ll find, while the AP dev watchlist created by me is slowly growing. I invite anyone to suggest improvements on the issue tracker, or to become a co-maintainer of the wiki.
As for solutions to manual list aggregation might be using the Murmurations protocol, for which I started two topics:
(These are more focused on documentation; other topics on this forum that go deeper into capability discovery and negotiation a la NodeInfo).
On the whole a serious issue of ‘slow’ Fediverse evolution is that most people are all too happy to work on own projects, but none to willing to spend any time to collaborate across projects and solidify the foundations on which their project stands.
I compared us to Spiral Island, a beautiful though fragile island made with - what other people consider - trash, floating precariously in rough seas of bad tech (the real Spiral Island was destroyed in a hurricane). I’ve been trying to rally others to help build an archipelago, pointing countless people to this community and created Fedi Foundation as a site for community empowerment.
Thus far there hasn’t been much enthusiasm, and I may repurpose the website for my own projects which are on hold because of time spent on advocacy. (I guess I’m finding that “grassroots” means ‘individualism with coincidental encounters along similar interests’). It is what it is…
Okay. I’m bad at reading between the lines, which only gets worse when a text is not in my native language.
none to willing to spend any time to collaborate across projects
It takes two to tango.
Thanks for this. I hadn’t thought about the categories but they do help when thinking about markets. Your point about very different people is a big one as well. Being social creatures, I imagine people follow their friends wherever when they see them having more fun “over there.”
These lists are great. I played around with some of the numbers in the fediverse.party git and was surprised to find more networks (aardwolf, ganggo, postactiv) that made appearances over the past few years.
It would be interesting to survey people on how they chose the platform/server they’re on. How many were via a directory, how many followed a friend, or read a story or did a random web search. Data collection seems to be a challenge but if the value is clear and data anonymized, then it should be possible to provide better guidance on growth.
And doesn’t this sum up FOSS development at large.
I’ve been listening to a lot of Pieter Hintjens and I really liked his focus on problem solving. Devs like to solve their own problems. There’s also a philosophy he fostered in ZeroMQ of minimal sanity checking + merge everything which helps devs feel valued. If they submit a PR it’s not going to be perfect, but with linters and tests and an aggressive bias toward merging, they’ll know what they’re getting into when they press the button… and it pushes the quality enforcement to the edge node (the dev) which I find much better aligned to decentralized systems than epic discussions happening in github issues.
Maybe taking decentralization to the core of the development process, removing any sort of social gatekeeping could help bring more devs in, among other things. Might just be that it’s what I’m listening to now so everthing’s a nail.
Thank you As for the survey… might start with a basic poll in a toot to get a first feel of how people encountered the fediverse.
I guess that’s true. But in a normal FOSS project there’s less risk in not being involved with, say, the programming language evolution or projects you depend on. Maybe ‘risk’ is not the right word, but federated project devs bought into a vision of highly interoperable apps, and are passionate for the culture and community vibes of the fediverse.
But the fediverse has no project driving it forwards. There is no organization conveniently publishing the next standard, or bring forth a new release to update your dependency against. It’s community all the way down. Not participating means stalled progress, or a dead end eventually.
Could you elaborate on this? I wrote United Software Development: A new paradigm? but that is probably not what you mean…
Sure, the way I understand the model that Hintjens/ZeroMQ implemented is that the software isn’t designed to a grand vision but grows in different ways as it solves problems as they come up. An issue, which could be a bugfix or a new feature, is stated as a problem and the community is free to argue whether it’s the right problem, or not a problem, or if accepted to be a real problem it is prioritized vs. others. Then developers take a problem from the stack, solve it with a PR which barring build failure gets merged.
A clear and mechanical policy on merging means that there is some risk of breaking the build, but that tends over time to trigger stronger build processes, more test coverage but … and here’s the attractive bit for me, developers get the satisfaction of committing code. The debate all happens at the problem definition phase. The developer has the freedom to create and of course it won’t be perfect but the project will keep moving. Developers who are satisfied have a higher chance of sticking around to keep solving problems. To hear Hintjens describe projects that use this, the main branch moves fast while maintaining high quality.
Much the same way that ActivityPub is a protocol that enables federation, a protocol for merging code centered on contracts and scripts for build/test can unleash a tremendous wave of development.
Using Ctrl-F on “:” actually gives a decent count of projects, “” for the AP supporting ones, and " - " for the It’s dead Jim section. There are some exceptions so I was just going to suggest a few edits to enforce that convention and probably very niche utility.
@weex could you recommend anything particularly interesting from Pieter Hintjens that I could listen to/read?
I’ve worked once in such a team where we practiced what I call “post-integration code review” and enjoyed that culture very much. Later on tried to advocate for it but was unable to convince my managers to change practices except having one master branch instead of many long lived feature branches. They didn’t trust the developers and the argument was that we don’t have good enough tests (what, as I believe, was a consequence of the process and organization structure we had). I built CI pipeline but was unable to influence high level org structure, which was decided 5 levels of manages above me… at least I had the team on my side they knew how much everyone - and me in particular - struggled with the process we had.
In case you wanted to dig in that, the description of my desired development process at that time is here: Cloud discharge - Google Docs (point 1. in proposed solutions section), might be worth moving to separate document one day. Interestingly to what @weex you wrote about separating problem (discussed and worked on collaboratively) from solution (implementation, for devs a way of expressing themselves and a subject of individual craft) I wanted to create strong division between feature suppliers (business) and consumers (developers who implement them). It was an infrastructure heavy project that we worked on, cloud object storage, so the distinction of both was not strong, and I felt like people who do not understand code interfere with it way too much.
(post-integration code review)
It shifts ownership of quality from a tester to the developer.
Code review becomes more like having someone curious reading your code and sharing their thoughts than bug hunting as in traditional flow (hardcoded and promoted by github, btw). It focuses much more on internal code quality (structure and readability of the code) rather then correctness and not breaking-anything. It totally changes dynamics and ends up with better quality, wherever it started.
Devs don’t have to wait for approval to integrate their changes. They feel empowered to take ownership, and as I’ve seen have never been irresponsible. It’s not about seniority, even junior devs can assess the risk of their changes and if unsure, ask someone to give a look at the change before merging it. On the other side the responsibility of not braking anything that was already working is on the person who wrote the feature and did (or not) protect it with automated tests. Usually new code is behind some sort of feature flags anyways and not visible to users until it is decided to turn it on.
Not sure if it is adaptable to oss projects where people come and go, and there is no mechanizm that would convince them to write tests. Maybe if they started from writing tests for the features they work on? Practicing executable specification, expressed as tests. Hope to try it in the fedihospex project. The Definition of Done is already there
I’ll respond to the rest of your comment when I have more time but this is the best resource I’ve found from Hintjens so far. 6. The ZeroMQ Community | ØMQ - The Guide
Unfortunately I also have this experience with some team processes being better than others. I took a look at your doc and see a lot of similarities between where you were trying to go and this Hintjens/C4 approach.
I’m jazzed about Hintjens work because he’s the first I’ve seen to flesh out and test a top-level protocol for free software development. The best I’d found before was more focused on the why rather than how.
The next step after digesting that guide and reading the C4 spec is that I want to try this whole approach out with a project. It might start by forking something that exists or creating something new. In the guide, Hintjens recommends starting with a crazy and simple goal. I came to this entire space with the desire to improve FOSS social networking perhaps through a scientific approach and am trying to put that impetus into crazy/simple terms.
If you’d like help applying this C4 process to your fedihospex project, I’d definitely be interested to contribute. I have zero experience with hospitality/hostels but I’m sure there’ll be plenty of opportunities to help on the organization/protocol side.
Do you have plans for Friday 6pm CEST yet? We’ll be happy to meet with you at our Fedi Hosp Ex office hours aka weekly meeting - HedgeDoc . You can also join our matrix room.
Thanks for sharing! I read it and liked very much. It’s pretty close to what one of my teams did, it was around 2012/13 that I joined that team so I wander if our tech lead new about it.
There were slight differences, we didn’t have branches (same as C4) nor used forks (different), we were pushing and rebasing directly to/on master. It was quite big team of ~30 devs and grew to ~50 working on the same codebase so by integrating often we could avoid conflicts and rework later. We also had pre-commit hook that run sanity checks on the patch before it was accepted to the master.
The other new thing to me is putting features and bugs to one box of issues presented as problem + solution. I’m used to have one backlog for them, but features were usually expressed as user stories with acceptance criteria etc and bugs are bugs. In fedihospex we have “ideas” bin so far, prioritized by user votes. Maybe both approaches are not contradictory though. I am curious to try it out, and rewrite everything to open problems.
Maybe you’d like to focus on Open Science realm then too, to combine things. I feel there are quite a number of fedizens that are interested. See: Proposal: New top-level forum section for Domains - #8 by aschrijver
The idea actually came from Hospitality Exchange which has little to do with hostels. It’s a network of people who welcome strangers to their homes, and travelers who need to stay somewhere at night and share their stories with the hosts. Bicycle touring community had a platform (160K users dispersed worldwide) built by the community whose board started to make money on the community recently. At first the source code of the server was closed (2015), people who disagreed with the board decisions were silenced (removed accounts) and now new members have to pay to join the community and to use the app (which for many regions with little infrastructure is the only option but not affordable at the price it is). I was contributor to the old, community built WarmShowers android app first released in 2012, which had 55K installs ever since, and which was called a security threat at the beginning of the year when the board released new, payed app and urged everyone to switch to it.
Could it be: Reclaiming hospitality from exchange platforms back to human interactions. ?
(which seems to me true but kind of too aggressive)
Here is some more background and sources of inspiration to form a better crazy, beautiful and easy goal:
- a message that we display to the users of our app (currently 20K devices): https://warmshowers.bike
- a survey with our pitch (with 1150 answers so far): https://warmshowers.bike/survey
- github issue describing why we want to federate: Federated Platform · Discussion #9 · FediHospEx/fedihospex.github.io · GitHub
- and last but not least, our project’s website with somehow better structured ideas for the future: https://fedihospex.github.io
I can’t make that particular office hours, though I can the next week. I did join your matrix and got into the Trello. Lots of great stuff!