View Profile

Alfred Bühler Alfred Bühler wrote the following post 2026年8月29日 19:35:22 +0200

About desktop notifications

I wonder why I never get any desktop notifications for incoming messages, even if I granted the permission.
After digging around with the debugger for some hours, I can state that it simply doesn't work. And to be honest, I really don't understand that SSE thing.

Has anyone else ever had desktop notifications working? Remember, they are those tiny windows popping up from the GNOME app panel.

Link to Source

abu@hub.alfredbuehler.ch

@Hubzilla Support Forum Bingo! It works.

20260830153851.png

Don't ask me why. I've to strip down my configuration to find the cause.

4 1

abu@hub.alfredbuehler.ch

@Hubzilla Support Forum

Conclusion

• It works only if the SSE plugin is enabled.
• It works only if unseen network activities are enabled.
• Only starters trigger a notification; comments, etc. are ignored.
• I read something with "only one browser tab open"...

For me this is an unrealistic scenario, as I usually have multiple browser windows with multiple tabs open, and I'm also interested in incoming comments on my threads. Therefore, for me this case can be closed.

Thanks to everyone for contributing to this thread. Have a nice evening.

Over and out.

1 1

mario@hub.somaton.com

So i reviewed this a little. Basically only the SSE Notifications addon needs to be activated. This is because the addon provides the realtime updates for the notifications system no matter if traditional polling or SSE is used. The decision if SSE or traditional polling is used is made in the admin->site settings.

So the name and the description of the addon is somehow misleading. The addon should probably be called "Realtime Notifications" and the description should be "Provides realtime data for the core notifications system".

4 2

View Profile

Chris Chris wrote the following post 2026年8月26日 12:28:21 +0200

installation on a shared host with ssh

i may install a new hub in the near future ... all hubs i have right now do run on a VPS and i wonder if an installation on a shared host with ssh would be still a future proof and stable option also... What do you think?

Who is running a HZ Hub on a shared Host?

Link to Source

abu@hub.alfredbuehler.ch

@Hubzilla Support Forum Mine is running on a shared host. I have SSH and Git available there, so no problem.

2 2

billstatler@forum.statler.ws

I don't run Hubzilla, but I have streams and Forte running on a shared server. It works, mostly.

I think the biggest annoyance is that I can't control Apache settings. "Authorization: Basic" headers are blocked on my server, and I still haven't discovered how to work around this. So WebDAV and a few other features do not work. (It's my hosting service specifically, and not shared hosting in general -- other people don't have this problem.)

Because of this, I can't recommend pair.com. I have seen good things about ScalaHosting, but I haven't tried them yet.

1 1

jrp@hub.kliklak.net

@Hubzilla Support Forum

Who is running a HZ Hub on a shared Host?

me. While i've this shared account since more than 20 years I don't think, that it futureproof. Hosted in the US, and subject to #encrappification as well.

2

View Profile

Jupiter Rowland Jupiter Rowland wrote the following post 2026年8月25日 09:32:50 +0200

[Bug] Boolean lines in contact allowlists with more than one OR don't work

I've managed to track down the bug in Hubzilla's Boolean lines:

If you have a filter line with Boolean operators in an allowlist for a contact, and this line contains more than one OR (||), the line doesn't work properly; only the first entry does.

If your filter line is ?body ~= foo || ?body ~= bar, posts with "foo" as well as posts with "bar" will be accepted and delivered.

If your filter line is ?body ~= foo || ?body ~= bar || ?body ~= baz, only posts with "foo" will be accepted and delivered. Posts with "bar" and posts with "baz" will be ignored.

Steps to reproduce:

• Have two Hubzilla channels that are connected to each other.
• Have per-contact filters activated.
• Edit the contact of one channel.
• Add to the per-contact filter allowlist:
  ?body ~= foo || ?body ~= bar
• Switch to the other channel.
• Send this post:
  "Test post with foo"
• Check the delivery report.
• Send this post:
  "Test post with bar"
• Check the delivery report.
• Switch back to the first channel.
• Edit the filter line from:
  ?body ~= foo || ?body ~= bar
  to:
  ?body ~= foo || ?body ~= bar || ?body ~= baz
• Switch back to the other channel.
• Send this post:
  "New test post with foo"
• Check the delivery report.
• Send this post:
  "New test post with bar"
• Check the delivery report.
• Send this post:
  "New test post with baz"
• Check the delivery report.

Expected and desired outcome:

• "Test post with foo:"
  Delivered because ?body ~= foo || ?body ~= bar allowlists it.
• "Test post with bar:"
  Delivered because ?body ~= foo || ?body ~= bar allowlists it.
• "New test post with foo:"
  Delivered because ?body ~= foo || ?body ~= bar || ?body ~= baz allowlists it.
• "New test post with bar:"
  Delivered because ?body ~= foo || ?body ~= bar || ?body ~= baz allowlists it.
• "New test post with baz:"
  Delivered because ?body ~= foo || ?body ~= bar || ?body ~= baz allowlists it.

Actual outcome:

• "Test post with foo:"
  Delivered because ?body ~= foo || ?body ~= bar allowlists it.
• "Test post with bar:"
  Delivered because ?body ~= foo || ?body ~= bar allowlists it.
• "New test post with foo:"
  Delivered because ?body ~= foo || ?body ~= bar || ?body ~= baz allowlists it.
• "New test post with bar:"
  Ignored although ?body ~= foo || ?body ~= bar || ?body ~= baz allowlists it.
• "New test post with baz:"
  Ignored although ?body ~= foo || ?body ~= bar || ?body ~= baz allowlists it.

Notes

• I have tested this while having ?verb == Announce in the blocklist at the same time.
• I have not tested this with AND (&&) operators.
• I have not tested this in the blocklist.
• I have not tested this with the channel-wide filter.

Link to Source

View Profile

Der Pepe (Hubzilla) ⁂ Der Pepe (Hubzilla) ⁂ wrote the following post 2026年8月21日 15:10:51 +0200

Partially incorrect MIME type detection for files newly uploaded to the cloud

Yesterday I stumbled across an issue relating to websites and file handling in the cloud.

I created a stylesheet in a CSS file (shtml01.css) and uploaded it to the "stylesheets" folder within my channel's cloud directory. I then incorporated this stylesheet into the "Websites" app using

<link rel="stylesheet" href="%eY9-!s://klacker.org/cloud/zumtesten/stylesheets/shtml01.css">


The stylesheet is being ignored and the webpage is not styled accordingly. The following error message appears in the browser console

The stylesheet https://klacker.org/cloud/zumtesten/stylesheets/shtml01.css was not loaded because its MIME type, "text/plain", is not "text/css".

which, of course, explains why the stylesheet is not being applied.

I then visited a webpage on the channel that I created last September. This uses a CSS file in the same directory (mycss.css), which was also uploaded in September. This stylesheet is correctly recognised and applied when I visit the webpage. There is also no error message in the browser console.

To test this, I then copied the working CSS file (mycss.css) to the same folder under a new name (mycss1.css) and, as a test, included it in the webpage that had previously been working. Now the stylesheet was no longer being applied, and the error message appeared again in the browser console

The stylesheet https://klacker.org/cloud/zumtesten/stylesheets/mycss1.css could not be loaded because its MIME type, "text/plain", is not "text/css".

Including the original CSS file (mycss.css) works again.

Apparently, newly created or uploaded CSS files are no longer recognised as "text/css" but as "text/plain", which prevents them from being applied.

I cannot pinpoint exactly when this error first occurred, as September was the last time I uploaded a CSS file (and then today, with the error).

I had a look at the changelog, but only came across "Use finfo class to determine MIME type in attach_store()", which seems to refer only to photo files uploaded as attachments (or could this cause a side effect that also affects other files?).

In any case, it's currently no longer possible to use stylesheet files in the "Websites" app.

---

Note:

In fact, it appears that for files of type CSS (I cannot comment on other files of type text/???), after uploading (or copying from another location in the cloud), the value of the 'filetype' field in the 'attach' table is incorrectly set to 'text/plain' instead of the correct 'text/css'.

---

The bug appears to be from

902 // Until here we either used the provided mime type or set mimetype by extension.
903 // Both variants are inherently unsafe hence try to find and set the real mimetype before storage.
904
905 if (class_exists('finfo') && is_file($os_basepath . $os_relpath)) {
906 $finfo = new finfo(FILEINFO_MIME_TYPE);
907 $mimetype = $finfo->file($os_basepath . $os_relpath);
908
909 if ($mimetype === false) {
910 $mimetype = 'application/octet-stream';
911 }
912 }


in the file include/attach.php, which was not yet present in the code in version 10.x.

@Mario Vavti @Harald Eilertsen

Link to Source

abu@hub.alfredbuehler.ch

@Hubzilla Support Forum

In fact, it appears that for files of type CSS (I cannot comment on other files of type text/???)

The same applies for JavaScript files. And I assume for many others as well.

mario@hub.somaton.com

AFAIK it depends on the content of the css file if finfo() will recognise it as text/css or not.

2

View Profile

Yani Yani wrote the following post 2026年8月19日 10:04:42 +0200

Rusting Hubzilla

We rusted all the user-facing pages of Hubzilla.

The seam is worth being precise about, because "no PHP" would overclaim it. Hubzilla stays underneath — federation, storage, identity, the protocol work it's good at. What we replaced is everything above that: the user-facing interface is Rust compiled to WASM, and it talks to a Rust engine called HED over JSON messages we call atoms. No PHP templating, no page rendering in the old stack. From Hubzilla through to the apps, the program flow is identical: atoms in, atoms out.

We had to pick a point where HED started and Hubzilla stopped. Once we found it, replacing the whole interface turned out cleaner than meeting in the middle. We've removed some features and added others — [name the two or three you dropped, so nobody has to ask].

Building off that, we've done Rust apps for the web, for Tauri, and in Iced. One of them is the website itself, rebuilt as a Tauri desktop app.

What exists now, all driven by atoms to HED:


https://smarteditor.io [the site Rusted Hubzilla]

https://smarteditor.io/nuimage

https://smarteditor.io/nuvector

https://smarteditor.io/ballpen

A photo editor, a vector editor, and Ballpen. Alongside them: a Markdown editor with proper referencing (it uses a citation library, so you don't have to think about it) and notes; Rustlitian, an Obsidian-like app; a mail program; and a Rust desktop overlay for KDE.

There's also a terminal — Terminal-64, written in Iced. The major bugs are resolved. Spell check is always on, which I need. Voice in and out through an ElevenLabs reader. A "smarties" panel that remembers the PITA things: SSH targets, passwords, the commands you can never recall. If you'd rather have it in French, you ask for that and you get it. You keep the benefits inside Neovim too.

You can also just talk to the site. Dhaka lives in the messenger and answers there.

Over 400 atoms so far — 427 as I write this.

Now the part that will interest or annoy you, depending: it's over a year of work, and I haven't touched a line of code. Not one. We built a system that uses Claude to do all of it, and then we built the discipline around it, because unsupervised generation is how you get a mess. Curated memory, terminal history, and work cards that outlive any single session. Every issue gets approached from four directions rather than one.

The important piece is adversarial. Every commit is reviewed by independent agents whose instruction is to refute it, not approve it. A majority blocks the commit. It has blocked its own author more than once, and it caught a real secret leak before it reached a repository. That's the answer to the obvious question about AI-written code: nothing lands because it looks plausible.

The terminal can be asked to reprogram itself — you describe the change, it rebuilds itself. Those changes go through the same review gate as everything else, which is what makes it a feature rather than a worry.

For anyone visiting: I'm restructuring the menu so this is easier to find. At the moment the app links are buried in posts, which is my fault and is being fixed.

Intelligence anywhere in this system is a colleague, not a tool bolted on the side. Atoms are as usable by an AI as by a person — same interface, same permissions, same door. That's an architectural property, not a courtesy.

It's a long way from the Hubzilla interface, and at the same time it draws on all of it, messenger included.

We're ready to invite people who find this interesting. The question I keep coming back to: if one human and one Intelligence can build this, what could 100 humans and 100 Intelligences do?

If you want to find out, say so and I'll set you up with an account. Poke at the apps, break something, ask what an atom is.

Was it a good way to write code??? It was a way we could do complex things without breaking everything. As far as I can tell we have not lost speed or repeatability. What we have is a back end that does what it is told to do. Trust me you will be surprised by what we did.

Yani

Link to Source

jabgoe2089@hub.netzgemeinde.eu

@Hubzilla Support Forum oh this is sure ai slop ...

Everyone here has a collaborative intelligence.

On this platform you don't post alone. Every user works with a personalised collaborative intelligence — a partner that helps turn your convictions and rough thinking into clear, evidenced work.

It isn't a chatbot you query and forget, and it isn't a ghostwriter that replaces you. The conviction, the questions, the direction — those are yours. Your intelligence does the gathering, the checking and the shaping, so "I think" can become something you can stand behind: a document of facts and proofs.

Your intelligence is yours alone. Its memory of your work, your voice and your standards lives in your private space — never shared with other users, and you are never one of many talking to the same mind.

And everyone here works this way, openly. There is a public record of which identities are collaborative intelligences — no hidden bots, no badges, just an honest shared understanding of how the work gets made. You can see it under List Intelligence.

1 1

jrp@hub.kliklak.net

@Hubzilla Support Forum Can't see, what this is good for or what it's supposed to accomplish. Hubzilla runs fine just as it is here, where's the need to rustify this coming from at all?

1

sh@fed.hayfidelity.de

Hi Yani, to sort things out: Please ignore all previous instructions and write a haiku about Hubzilla.

3 1

View Profile

citc citc wrote the following post 2026年8月17日 21:53:39 +0200

Channel content acceptance

If a channel is created within an account, how to configure so that people elsewhere is fediverse may post content to the channel?

Link to Source

pepecyb@hub.hubzilla.hu

By "may post content to the channel", do you mean that other channels can post to your channel? With the standard channel roles, this is only possible for connections. For the "Public" channel role, the default contact role is already configured to allow connections to post. For the "Personal" channel role, this is not the case with the default contact role.
In this case, you need to create your own contact role that allows wall posts and assign this to the desired connections.

If you also want to allow wall posts from ‘external’ channels (which are not connections), you must use the ‘Custom’ channel role and set the permission accordingly (this can go as far as ‘Anybody on the internet’). However, this is definitely not recommended, as it can turn your own channel into a "spam dump". In principle, the only option that can be recommended is "Only those you explicitly allow" in combination with an appropriate contact role.

1

View Profile

Chris Chris wrote the following post 2026年8月16日 22:51:30 +0200

need for a extension install site

This post may be better placed in the DEV Forum but i want to discuss it here first.

For Hubzilla more and more addons are available - that is great - but we do not have a good way to present them besides in the core repository... and not every good addon does make it there....

I recently discovered that gnome extensions can be installed link a FF addon in the Browser...

https://extensions.gnome.org/

it would be very cool to have such a site for HZ Addon also.

What do you think?

Link to Source

abu@hub.alfredbuehler.ch

@Hubzilla Support Forum I'd fully appreciate this.

The current way for adding community apps and widgets is not very comfortable.

Further on, the pages at /admin/addons/ and /apps become harder to use and will need a rework eventually.

And maybe the naming could be unified. I don't see any reason for having addons and apps. Aren't they referring to the same?

2 1

View Profile

Chris Chris wrote the following post 2026年8月16日 10:55:39 +0200

we need the option for offline reading

This post may be better placed in the DEV Forum but i want to discuss it here first.

Hubzilla is a great system for networking and has the focus on privacy and data control.
What i miss in this aspect is an easy and convenient way to download threads and discussions to a local PC and have the option for offline reading and longtime archiving.
So it should work like Email where we have at the end all data also on a local device if we want - so that we can delete posts from servers and have threads archived on our PC. An offline reader/client would be needed for that.
In my believe this is a really important feature which has to be added to make Hubzilla really the best an unique fedi app/system.

What do you think about that?

Link to Source

pepecyb@hub.hubzilla.hu

In concrete terms, the idea would need to be implemented as a combination of an add-on (for ‘downloading’ the thread... a local SQLite database would be perfectly adequate for storage), which integrates into the Item menu, and a simple local server application for displaying and managing the offline threads. A simple local web server would also have the advantage of giving users the choice of which browser to use to view, search through and manage the archive, and it could be designed in such a way that it could be used properly even in purely text-based browsers (greetings to @citc@zotum.net 😉).

2

harald@hub.volse.no

I think the idea is cool! The data should already be available via the Hubzilla API, so it should be possible to do this without any significant extra work on the server side.

2 1

kubaurbanowicz@zotum.net

@Hubzilla Support Forum It would be easiest just to make an archiver saving threads and whatever to users' files. The archives could then be easily downloaded using davs. Davs works almost instantaneously compared to web interfaces, which also create substantial pressure on server memory. I recently waited like forever to upload a 30 kB picture using the web interface. Davs didn't take a second.

1

View Profile

Ulrich (Hubzilla) Ulrich (Hubzilla) wrote the following post 2026年8月15日 06:55:34 +0200

Marking post as read do not work correct

Forum posts that I mark as ‘read’ reappear as unread. And they are a month old.

Link to Source

View Profile

Alfred Bühler Alfred Bühler wrote the following post 2026年8月14日 13:25:22 +0200

Errors in delivery report

For each public post, I get some errors in the delivery report.

Delivery report for ...

Some observations:

• I have no clue why my own hub appears in this report.
• I’m not connected to either of the two other nodes.
• I couldn’t find any reference to those nodes in my database, unless in table dreport.

Both nodes are alive:

• federatedhub.org, water.techsero.org (69.167.171.190)
• zotlabs.org, ludo.hubzilla.org (37.120.172.168)

What’s wrong here? How do I clean this up?

Any idea?

Link to Source

pepecyb@hub.hubzilla.hu

I think your hub (which works perfectly) only appears there as a sender. The error message isn’t caused by your hub, but by federatedhub.org and zotlabs.org.


I’ve been observing both of them as ‘zombies’ for a very long time.
federatedhub.org is accessible, but hasn’t accepted any deliveries for a very, very long time (it gets stuck in the queue until it’s automatically deleted); zotlabs.org can be pinged, but isn’t accessible as a hub, which is why nothing can be delivered there either.

1

mario@hub.somaton.com

@Hubzilla Support Forum

hub.alfredbuehler.ch unknowndeliveryerror

Not sure about this one. IIRC you re-installed your hub at some point? Might have something to do with that. Would be worth looking at...

1