Hubzilla Use Cases

2025-04-15 19:50:01

Hubzilla Support Forum

adminsforum@hubzilla.org

Scott M. Stolz wrote the following post Tue, 15 Apr 2025 19:50:21 +0530

Hubzilla Use Cases

Started a new thread. Originally from this conversation in the @Hubzilla Support Forum.

Poul Udbye Pock-Steen wrote the following post Tue, 15 Apr 2025 18:04:51 +0530

@Scott M. Stolz

One thing that I think would help is creating a website that explains the use cases for various technologies, and well as providing links to relevant resources related to those technologies

What do you mean exactly, with 'technologies'?

I am not sure if that is something you are interested in, but that is one of many projects in progress. We'd love the help, if you are willing to contribute.

I would be happy to participate!

I also think it’s important to create a public collection of use cases describing the technical behavior that Hubzilla can expect from platform X — and what platform X can expect from Hubzilla — when establishing a meaningful conversation via ActivityPub.
Obviously, there are things shared by Hubzilla that platforms like PeerTube, Mastodon, or Pixelfed won’t be able to handle meaningfully, mostly due to the different intentions and structures behind the applications.
In the best of all worlds, though, basic elements like short text, photos, videos, links, etc., should be exchanged meaningfully between Fediverse platforms.

But as things stand, that’s not the case — and I think we need to map the current compatibilities (and incompatibilities) between the different platforms.
For instance, if a Hubzilla channel can subscribe to a PeerTube video channel, then Hubzilla should be able to provide a meaningful (and shareable) presentation of the PeerTube post. And if that’s not the case, it would be helpful for everyone to know whether it’s due to structural differences, simple bugs, or misinterpretation of the protocol.
If Hubzilla can follow a Pixelfed account, why can’t it send or receive photos to/from Pixelfed? Is it due to structural differences, bugs, or interpretation discrepancies? And so on.
We need to map these technical behaviors — even if it’s not Hubzilla’s “fault” — in order to establish meaningful communication with as many platforms as possible, potentially even bridging beyond the Fediverse, like with Bluesky.

That would help bring Hubzilla to the position it deserves.

show all 32 comments

2025-04-15 20:24:35

Scott M. Stolz

scott@loves.tech

@Poul Udbye Pock-Steen

What do you mean exactly, with 'technologies'?

The two biggest technologies that we would like to spread are Nomadic Identity and Federated Single Sign On.

Federated Single Sign On

This allows you to "remotely authenticate" on another platform or website or app with your existing Fediverse identity. The technology we use is OpenWebAuth (also called @Magic Sign On). You've probably used it multiple times while using Hubzilla.

One use case I am particularly fond of is being able to sign onto another platform, such as a forum, and post using their interface. That way, even though, let's say your account is on Hubzilla, you could sign onto @NodeBB using your Hubzilla account and use NodeBB's interface to participate in the NodeBB forum. And vice versa.

Nomadic Identity

This allows your identity and content to be synced between two or more servers. You can use any of them to interact with the fediverse under the same identity. You have a primary account and you have one or more have clones.

This provides a couple of functions. First, it provides a synced backup of your identity and content. If one server goes down, you can log into the other server and continue like nothing happened. You can also download an offline backup that can be uploaded to a new server. It also makes it easy to migrate to another server. You clone your account, make that clone primary, and delete your old account.

We also want to spread other technologies, such as Conversation Containers for threaded conversations, but those apply to a subset of platforms, whereas the two mentioned above could be implemented by most platforms, if they chose to.

2025-04-15 20:30:06

Scott M. Stolz

scott@loves.tech

@Poul Udbye Pock-Steen

I would be happy to participate!

Thank you. I invite you to join the @Hubzilla Documentation Team forum. We would love to have you.

2025-04-15 20:55:01

Scott M. Stolz

scott@loves.tech

@Poul Udbye Pock-Steen

I also think it’s important to create a public collection of use cases describing the technical behavior that Hubzilla can expect from platform X — and what platform X can expect from Hubzilla — when establishing a meaningful conversation via ActivityPub.

I agree. Increased compatibility between platforms is something I would love to see.

Obviously, there are things shared by Hubzilla that platforms like PeerTube, Mastodon, or Pixelfed won’t be able to handle meaningfully, mostly due to the different intentions and structures behind the applications.

In the best of all worlds, though, basic elements like short text, photos, videos, links, etc., should be exchanged meaningfully between Fediverse platforms.

Hubzilla is in a unique position because Hubzilla can be extended. People can create addons that change how things work or are displayed.

For example, let's say that Hubzilla encounters a post that is from PeerTube, Loops, or a video from Pixelfed. If we are able to detect that the post is a video post (not just a note with a video in it), then we could change up the single post view so that it looks more like a video player with comments instead of a text post with an embedded video. We could also give the same treatment if someone uploaded a video to Hubzilla.

If someone were willing to build it, Hubzilla could, via an addon, become a PeerTube peer.

To do something like that, we would need additional information, because most posts are transmitted as "Notes" over ActivityPub, mostly because Mastodon prefers Notes, displays "Articles" as links, and ignores many other types.

Ideally a video should be type "Video" instead of a "Note" but we would break compatibility with Mastodon if we do so. So coming up with some way to mitigate that would be ideal.

Documentation and collaboration would help in this endeavor.

2025-04-15 22:11:04

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@Scott M. Stolz

Ideally a video should be type "Video" instead of a "Note" but we would break compatibility with Mastodon if we do so.

To be honest, it really gets on my nerves when other services (including Hubzilla) repeatedly subordinate themselves to the pseudo-standard of Mastodon. I was annoyed when the option to send ‘articles’ activity was removed because Mastodon then defaced every post from Hubzilla (and probably still does today)... namely as a link to the original.

Will the other Fediverse services ever manage to free themselves from this yoke?

2025-04-15 23:47:59

Scott M. Stolz

scott@loves.tech

@Der Pepe (Hubzilla) ⁂ ⚝ What I am hoping is that ActivityPub comes up with ActivityPub Version 2.0 (or whatever next version they designate) and that the platforms that use that standard use it properly (with Notes, Articles, Videos, etc. properly marked and displayed).

Platforms would have two choices. Stay with their current ActivityPub 1.0 implementation, which heavily favors how Mastodon does things. Or they can upgrade to ActivityPub 2.0 and implement it according to the ActivityPub specs.

For backwards compatibility, there will probably be a transition period where things are dual stack. If both of the platforms speak 2.0, they communicate in 2.0, otherwise it downgrades to 1.0. This is similar to how Hubzilla uses Zot if available, and (if ActivityPub is turned on) attempts to use ActivityPub if Zot is not available.

I think that is the only way we are going to transition the fediverse into using the ActivityPub specs instead of Mastodon specs.

cc: @Evan Prodromou @Evan Prodromou

2025-04-16 00:27:10

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@Scott M. Stolz

Hope springs eternal. 😉😁

I fear that Mastodon will not implement the AP2.0 specifications again either and that many services will then bend again to please Mastodon.

I'll just take the article <-> note problem again. Mastodon expects all posts to be ‘notes’. When it receives an ‘article’ type activity, it doesn't render the post, but simply throws a link to the original post into the timeline. This is of course a bad thing for Mastodon users. First of all, they can't see the content in their timeline like they can with all other content, and what's more, they leave their ‘home’ page by clicking on the link. Many will simply scroll away from such a link without comment, and the post will be lost to a good number of them. The same post sent as a ‘note’ is rendered correctly (by Mastodon standards). So: What's the problem with Mastodon not displaying articles normally according to this scheme? It can't create that many problems. They just don't want to, because as ‘the Fediverse’ they are the dictator of the federated network.

And that's just one example of how other services adapt (bend, bow) to be reasonably usable for Mastodon users.

Sorry... I'm just a little annoyed about this topic. 😁

2025-04-16 00:42:38

Scott M. Stolz

scott@loves.tech

@Der Pepe (Hubzilla) ⁂ ⚝ Well, the other option is to become bigger than Mastodon.

Which, if I think we came together as a team, could achieve.

Plus, if we create a knowledgebase with use cases and features, and how to implement them in ActivityPub (and perhaps Zot), we become one of the authorities on the matter. We can work with other platforms and developers to come up with something that works for us, and is still compatible with Mastodon.

Conversation Containers is a perfect example. Mike (and perhaps others behind the scenes) created something that is compatible with Mastodon, yet provides advanced functionality to platforms that can understand the additional data. The best of both worlds. We may have to come up with some unique solutions, but I think if we put our heads together with other platforms, we could come up with solutions.

2025-04-16 01:41:42

*_jayrope

jrp@hub.kliklak.net

@Scott M. Stolz Not going to work (becoming bigger than Mastodon) :grin:

2025-04-16 02:09:35

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@*_jayrope @Scott M. Stolz

Maybe not bigger than a mastodon... but more important!

2025-04-16 02:20:06

sk@utsukta.org

@Der Pepe (Hubzilla) ⁂ ⚝ it already is!

2025-04-16 02:25:15

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@SK 😁

2025-04-16 02:31:25

Scott M. Stolz

scott@loves.tech

@*_jayrope Think of it this way. Facebook is way more popular than Twitter ever was. And people seem to prefer the features and UI of Facebook over Twitter. We are more like Facebook than Twitter, in both features and UI. If we improve the onboarding and user experience (UX), and we launched several public hubs, and made it easier for people to run their own hubs, I think we would have a chance of at least be a major contender.

And Mastodon is not going to stay on top forever. Pixelfed is moving up in the ranks, especially if you look at active users. WordPress could easily outpace Mastodon if blogs decided to turn on ActivityPub en mass. Loops is also poised to become a major player. Times are changing.

2025-04-16 02:49:41

sk@utsukta.org

I think one way is to offer themes suited for particular purposes, @Der Pepe (Hubzilla) ⁂ ⚝ suggested developing blog based themes that would be appealing to writers, similarly a theme that is aimed towards photographers might add variety and appeal to broader userbase.

2025-04-16 12:31:02

Hamiller Hubzilla

hamiller@hub.hubzilla.hu

@Scott M. Stolz

I believe that the Thrediverse as a whole has a good chance of surpassing Mastodon over time. You just have to give it that time.

2025-04-16 16:21:22

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

If I understand this correctly, it means a huge amount of work.

What needs to be done is:

Test posting, commenting, DMing, reposting/repeating/boosting/renoting, sharing/quote-posting, liking, disliking etc. from Hubzilla to another Fediverse server application, trying as many features and variants as possible, and compare what Hubzilla produces with what the other server application shows.
Test posting, commenting, DMing, reposting/repeating/boosting/renoting, sharing/quote-posting, liking, disliking, emoji-reacting, embedding content etc. from another Fediverse server application to Hubzilla, trying as many features and variants as possible, and compare what the other server application produces with what Hubzilla shows.

This needs to be done:

from Hubzilla to Mastodon
from Mastodon to Hubzilla
from Hubzilla to Glitch-soc
from Glitch-soc to Mastodon
from Hubzilla to Ecko
from Ecko to Hubzilla
from Hubzilla to Hometown
from Hometown to Hubzilla
from Hubzilla to any other Mastodon fork
from any other Mastodon fork to Hubzilla
from Hubzilla to Guppe Groups
from Guppe Groups to Hubzilla
from Hubzilla to Pleroma
from Pleroma to Hubzilla
from Hubzilla to Akkoma
from Akkoma to Hubzilla
from Hubzilla to Misskey
from Misskey to Hubzilla
from Hubzilla to Calckey
from Calckey to Hubzilla
from Hubzilla to Firefish
from Firefish to Hubzilla
from Hubzilla to Iceshrimp JS
from Iceshrimp JS to Hubzilla
from Hubzilla to Iceshrimp.NET
from Iceshrimp.NET to Hubzilla
from Hubzilla to CherryPick
from CherryPick to Hubzilla
from Hubzilla to Sharkey
from Sharkey to Hubzilla
from Hubzilla to Catodon
from Catodon to Hubzilla
from Hubzilla to Neko
from Neko to Hubzilla
from Hubzilla to Meisskey
from Meisskey to Hubzilla
from Hubzilla to Tanukey
from Tanukey to Hubzilla
from Hubzilla to everything else based on Misskey
from everything else based on Misskey to Hubzilla
from Hubzilla to micro.blog
from micro.blog to Hubzilla
from Hubzilla to snac
from snac to Hubzilla
from Hubzilla to GoToSocial
from GoToSocial to Hubzilla
from Hubzilla to Mitra
from Mitra to Hubzilla
from Hubzilla to Socialhome via ActivityPub
from Socialhome to Hubzilla via ActivityPub
from Hubzilla to Socialhome via diaspora*
from Socialhome to Hubzilla via diaspora*
from Hubzilla to Friendica via ActivityPub
from Friendica to Hubzilla via ActivityPub
from Hubzilla to Friendica via diaspora*
from Friendica to Hubzilla via diaspora*
from Hubzilla to (streams) via ActivityPub
from (streams) to Hubzilla via ActivityPub
from Hubzilla to (streams) via Nomad
from (streams) to Hubzilla via Nomad
from Hubzilla to Forte
from Forte to Hubzilla
from Hubzilla to Lemmy
from Lemmy to Hubzilla
from Hubzilla to /kbin
from /kbin to Hubzilla
from Hubzilla to Mbin
from Mbin to Hubzilla
from Hubzilla to PieFed
from PieFed to Hubzilla
from Hubzilla to Wafrn
from Wafrn to Hubzilla
from Hubzilla to WordPress
from WordPress to Hubzilla
from Hubzilla to Ghost
from Ghost to Hubzilla
from Hubzilla to Flipboard
from Flipboard to Hubzilla
~~from Hubzilla to WriteFreely~~ (irrelevant because WriteFreely has no support for interaction yet)
from WriteFreely to Hubzilla
from Hubzilla to Plume
from Plume to Hubzilla
from Hubzilla to Pixelfed
from Pixelfed to Hubzilla
from Hubzilla to Vernissage
from Vernissage to Hubzilla
from Hubzilla to PeerTube
from PeerTube to Hubzilla
from Hubzilla to Loops
from Loops to Hubzilla
from Hubzilla to Owncast
from Owncast to Hubzilla
from Hubzilla to Funkwhale
from Funkwhale to Hubzilla
from Hubzilla to Bandwagon
from Bandwagon to Hubzilla
from Hubzilla to Castopod
from Castopod to Hubzilla
from Hubzilla to Mobilizon
from Mobilizon to Hubzilla
from Hubzilla to Gancio
from Gancio to Hubzilla
from Hubzilla to BookWyrm
from BookWyrm to Hubzilla
from Hubzilla to Inventaire
from Inventaire to Hubzilla
etc.

Of course, whenever either side is updated, the whole testing process must be repeated, and the results must be updated.

Also, of course, tests must be conducted against all versions of everything in productive use. In theory, this means that we may need a whole lot of Hubzilla hubs on various Hubzilla versions for these testing purposes to be able to emulate what happens in interaction between a Hubzilla hub that hasn't been upgraded to the latest release yet and e.g. over a dozen Mastodon versions.

2025-04-16 17:36:40

Scott M. Stolz

scott@loves.tech

@Jupiter Rowland The first part would be documenting how Hubzilla does it, and what the Fediverse Enhancement Proposals (FEPs) say.

That will provide a basis for collaborating with other platforms that want to collaborate. And a lot of that collaboration is being done behind the scenes already. We are just bringing some of it into the open.

Creating use cases and documenting how the protocol sends and receives information is NOT the same as testing every single platform against Hubzilla.

Testing is something different.

2025-04-16 18:37:37

Jupiter Rowland

jupiter_rowland@hub.netzgemeinde.eu

@Scott M. Stolz To quote @Poul Udbye Pock-Steen:

I think we need to map the current compatibilities (and incompatibilities) between the different platforms.

He wasn't talking about what things should be like in the best case. He was talking about what things are like right now.

Why doesn't Hubzilla receive new episodes from Castopod (except it does now, but it used to not)?

Why doesn't Hubzilla show links from Lemmy posts?

Why aren't PeerTube videos embedded in the corresponding posts when Hubzilla shows them?

Which text formatting features that Hubzilla can generate does Mastodon render, and which doesn't it?

Why is it that Mastodon replies have so many mentions, and does Hubzilla have to mention so many Mastodon accounts itself when commenting in a conversation that's largely Mastodon?

How does Mastodon handle Misskey's emoji reactions? How does it handle Misskey's quote-posts? Vice versa, how does Misskey handle Hubzilla's shares?

How come Hubzilla shows shared posts in posts from Friendica twice?

How do Hubzilla's permissions translate to (streams), to Forte, Friendica, to Mastodon, to Pleroma?

How does Hubzilla's event calendar federate with Mobilizon and Gancio, if at all?

Why does Mastodon only adopt the last hashtag in a last line of hashtags in Hubzilla posts instead of all of them?

How should Hubzilla handle Friendica-specific BBcode tags that arrive on Hubzilla as tags in plain sight, e.g. [em][/em], [strong][/strong] or [abstract][/abstract]?

And so forth.

2025-04-16 19:03:33 Last edited 3 days ago

Scott M. Stolz

scott@loves.tech

@Jupiter Rowland Remember, this can be a community effort, and not just our community. A lot of other platforms are very interested in interoperability, and the developers from these projects are actively working together behind the scenes already.

What we are talking about creating is a community resource, possibly created in wiki form, where people can contribute their knowledge.

We get the ball rolling by documenting what Hubzilla does, and what we know about compatibility with other platforms. We invite others to participate and help build out the knowledgebase.

We are in the perfect position to do so because we are a feature-rich platform. We can explain what some of these features are and how we implemented them. Point them to FEPs related to these features.

Worst case scenario, we have documentation that says how Hubzilla does it. Best case scenario, it becomes a fediverse resource that developers from other projects contribute to. Either way it is win.

Will it take work? Yes. But we need to document this stuff anyway. We might as well invite the rest of the fediverse to contribute in a way that benefits us, them, and the fediverse at large,

2025-04-18 01:10:52

*_jayrope

jrp@hub.kliklak.net

@Jupiter Rowland I am happy to see you expanded your work field :)

2025-04-18 01:34:50

Poul Udbye Pock-Steen

pup@classical.ballhaus.community

@Scott M. Stolz

What we are talking about creating is a community resource, possibly created in wiki form, where people can contribute their knowledge.

We get the ball rolling by documenting what Hubzilla does, and what we know about compatibility with other platforms. We invite others to participate and help build out the knowledgebase.

How do we get started?
Hubzilla has a wiki add-on, right? Could we use that?
Ideally, we should provide anyone who wants to participate with some form of template in order to ensure a certain level of coherence.

2025-04-18 01:49:10

Poul Udbye Pock-Steen

pup@classical.ballhaus.community

@Jupiter Rowland

And so forth.

You're absolutely right—a lot of work! But it's necessary for the Fediverse to become a functional network of federated platforms.
Anyway, we can enjoy the ride toward the accomplishment of this technological and sociological dream—little by little.
Rome wasn't built in a day! :-)

2025-04-18 01:51:32

*_jayrope

jrp@hub.kliklak.net

@Poul Udbye Pock-Steen

Rome wasn't built in a day!

Neither was any city ;)

2025-04-18 19:56:13

Scott M. Stolz

scott@loves.tech

@Poul Udbye Pock-Steen

Hubzilla has a wiki add-on, right? Could we use that?
Ideally, we should provide anyone who wants to participate with some form of template in order to ensure a certain level of coherence.

Yes, we can use Hubzilla's wiki feature, as well as the webpages feature. We can also create custom databases and display them in Hubzilla, if desired.

Templates would be good, as that would help create a consistent presentation. And a style guide would also be good.

We can also have editors. For example, I am fairly good at markup and organization, so I can go in and make it look pretty and structure the navigation so that stuff is easy to find. Other people with similar skills could also be editors.

2025-04-18 19:58:45

Scott M. Stolz

scott@loves.tech

@Poul Udbye Pock-Steen

How do we get started?

First, we would need neutral domains to store this stuff. I have several of them that we can use.

federatedhub.org - knowledge base - Information about various federated projects, which links to relevant resources.
development.guide - knowledge base - specifically for developers, including code examples.
fediverse.center - links to the knowledge bases and various fediverse-related information. Basically an entry point to find all of the other resources.

These would all be interlinked as if there were one resource. Each domain name just becomes a convenient way to jump to specific sections. Also, users and administrators may not be interested in the development stuff, so it would be good to have the overly technical stuff in a separate space.

We are also maintaining the following websites, and we can copy related information over so we don't duplicate effort. This also means that we can customize the message depending on the audience.

hubzilla.org - Hubzilla related documentation.
neuhub.org - Neuhub related documentation.
opennomad.net - Open Nomad Network - Nomadic Identity.
magicsignon.org - OpenWebAuth / Federated Single Sign On.

These would focus on the specific topics, so there is no distraction about other platforms.

I know that seems like a lot of maintain, but all we are doing is dividing the content we want to create onto multiple domains, and then interlinking them. It would be the same amount of work if we put them all on one domain name.

Also, some people may want to focus on specific topics. That way developers could work on the more technical dev stuff, and non-developers can work on the other sections.

I actually have a huge vision and plan for Hubzilla and the fediverse, but I can't implement it by myself. So any help is appreciated and welcomed.

2025-04-18 20:05:19

BauerUlli

bauerulli@hub.netzgemeinde.eu

Could there be a "German" corner?

2025-04-18 20:19:47

Scott M. Stolz

scott@loves.tech

@BauerUlli

Could there be a "German" corner?

Yes, one of the goals is to have multi-lingual websites. The Hubzilla core already has multi-language support, but the wiki addon would need some improvements to fully support other languages. I don't think it would be too hard to add, and there are multiple ways of doing it.

For example, we could have a wiki for each language that we want to support, and then create a widget that sees if there is a version in another language. We could also have the wiki page redirect to the language you set in Hubzilla if available, and to the English page if not available.

Or we could incorporate multiple languages directly into the wiki addon, which would eliminate redirects. It would just display the appropriate language. A bit more complicated, but probably more robust in the long term.

We would only want to maintain other languages if we have enough volunteers to maintain it though. I think we have enough people who speak German. We would just need volunteers.

2025-04-18 20:23:23

BauerUlli

bauerulli@hub.netzgemeinde.eu

I think there is a "Spendendose" necessary too

2025-04-18 20:38:39

Scott M. Stolz

scott@loves.tech

@BauerUlli There are two ways to accomplish something in a not-for-profit setting:

People donate their time and effort, or
they donate money and we hire people to perform certain tasks.

Donations would help. We could compensate editors, writers, and translators that way. Perhaps even create a bounty system, where creating certain things have a cash reward. But we would need to get donations before we could hire anyone.

2025-04-19 01:14:52

Der Pepe (Hubzilla) ⁂ ⚝

pepecyb@hub.hubzilla.hu

@Scott M. Stolz @BauerUlli

We would just need volunteers.

Apart from the fact that I will definitely be involved in this project, it goes without saying that I will make myself available for the translation into German and would certainly be happy to assist German-speaking readers.

2025-04-19 01:20:57

BauerUlli

bauerulli@hub.netzgemeinde.eu

Danke!
Englisch ist natürlich irgendwie am Ende einfacher/besser. Ich würde aber auch gerne irgendwie mitmachen. Das fällt mir auf Deutsch natürlich weniger schwer. Es gibt natürlich die Maschine.

2025-04-19 03:03:02

Scott M. Stolz

scott@loves.tech

@Poul Udbye Pock-Steen

How do we get started?

The websites that I mentioned are already up and have Hubzilla installed. I can set up the wikis and start structuring the websites to accept contributions.

The first thing we would want to do is figure out what we want to work on first, and then figure out who wants to do what.

What might be good is to start with an outline with the basic structure that we want, and some brainstorming on specific types of information that we want in there.

2025-04-19 04:47:51

Poul Udbye Pock-Steen

pup@classical.ballhaus.community

@Scott M. Stolz

The first thing we would want to do is figure out what we want to work on first, and then figure out who wants to do what.

What might be good is to start with an outline with the basic structure that we want, and some brainstorming on specific types of information that we want in there.

I agree. Let's start the brainstorming in a new thread right after Easter.
(As an organist, I have a lot of work to do over the next few days—I'll be back on track by Tuesday!)