pepecyb@hub.hubzilla.hu

It would be interesting to know how the translation process works. Does the add-on have its own translation engine and carry out the translations on the Hub, or does it use a translation service? If so, which one? What data is transmitted?

Thanks for helping me unearth some forgotten memories.

Of course feeds work as a channel source… you just need to have added them as a channel beforehand. I’d completely forgotten that. I’ll add it to my KnowledgeDB straight away!

In order to add a feed as a contact, this option must have been enabled on the Hub by the admin. Otherwise, the option to connect to feeds will not be available.
As far as I am aware, it is unfortunately not possible to use feeds for channel sources.

Why should it be replaced?

Good idea to enable slow log for another series of tests. I’ll do that.

Performance differences when accessing new vs old files does not make much sense to me though

That’s exactly why I’m confused. The only thought I had was whether it might somehow be down to the number of entries in the directory. However, the two directories do differ in the number of entries. What they have in common is the rather large total size (MB). I’ve no idea at the moment.

Several tests (in which the hubs consistently froze) showed no significant differences in the number of times images were accessed.

Nor did the method of referencing in the source code (i.e. <HUB>/photos/<HASH_FILENAME> or <HUB>/cloud/<CHANNEL_NAME>/<REAL_FILENAME>) make any difference. New images from the two problematic subdirectories caused the system to freeze, whilst images from other directories did not. I’ve now simply stopped using those two directories for new uploads… but that's obviously just treating the symptoms.

In view of the points outlined here, Hubzilla has a huge advantage: it is modular.


Even though the use of AI-generated code in the core is not permitted, Hubzilla offers the option of creating appropriate accessibility aids using AI. Special themes and/or (in combination with) relevant add-ons would be suitable for this purpose, and their installation would then be the responsibility of the Hub administrator. Hubzilla makes this possible.

I’m going to give that a proper go today to see if I can spot any differences.
I’ll get back to you as soon as I have the results.

That also seems rather unlikely, although the thought had crossed my mind too.

Example:

I upload the image A.png (a completely new image) to the “Artikelbilder” folder and embed it in a post: after a short while, the hub freezes and displays the error message in the log.

After rebooting, I delete the post and the image.

Then I upload the image A.png again to a different directory and use it in a post: no error occurs.

I upload a completely new image, B.png, to a different directory and use it in a post: no error occurs.

I upload the image B.png to “Artikelbilder” and use it in a post: after a short while, the hub freezes and displays the error message in the log.

Reboot, delete…

I move the image B.png from the other directory to “Artikelbilder” and use it for a post: after a short while, the hub freezes and displays the error message in the log.

The only thing that might explain this is that the issue does not occur with older images already present in the critical directories.

That’s what I’d suspected at first, too. But what sort of ‘configuration error’ could be responsible for files from certain directories suddenly timing out when referenced? I pushed my hub even further tonight (until it crashed with the error message). And it’s reproducible: files newly added to certain directories cause the timeout error. Older files already present in precisely these directories do not cause the error, even when reused in a post. The files that caused the problem do not trigger the error if I upload them to new directories (including sub-, sub-sub-… directories) or to other sub-directories that have existed for a long time, and then use them in posts.

If this error were to occur generally, that assumption would make sense, but as it only happens in a few specific directories – and only with newly added files (which, by contrast, cause no problems in other directories) – I no longer necessarily assume it is down to a misconfiguration. I have currently identified the problem in two directories…

Pepes pic (41.6 MiB, 208 files, 1 subfolder)
Artikelbilder (39.0 MiB, 120 files, 10 subfolders)

The channel’s entire cloud: 233.1 MiB, 1,118 files, 92 subfolders.

It’s unlikely that the theme is to blame. Hubzilla stored the files correctly in `store/pepecyb/` – both the original and the resized versions, with the hash value as the filename – and their paths are correctly referenced in the database within the ‘attach’ table. I’d checked this before deleting them. And it doesn’t matter whether I upload the file via WebDAV or from the web interface. Certain directories cause the error. BTW: These are directories, some of which contain over 200 files… which is why I became suspicious.

I’ve also tried this with Solidified, Redbasic and Adminlte. And whenever I’ve uploaded to one of the rather ‘full’ directories, the file was visible in WebDAV and on the web interface and could also be displayed, but when embedded in a post, the Hub freezes with the error mentioned.

HestiaCP?

I’m planning to add a chapter on this to the admin handbook. However, a page recommending suitable hosting providers would then have to go elsewhere.
The topic of backups is something that’s relevant to every type of hosting and could also be given its own chapter.

Well, you need to create a backup script. Either based on the snippet that @Alfred Bühler posted here, or, for example, as described in the admin manual, and name it something like hub-snapshot.sh.

Then you just need to create a cron job for it. So

crontab -E


and enter the following line, for example

0 2 * * * /path/to/hub-snapshot.sh >> /var/log/hub-snapshot.log 2>&1

(for a daily backup at 2 am).

You can also use https://crontab-generator.org/ to generate the correct cron job.

*_jߍyrope wrote:

then I get … just a white page

I’m in much the same boat. I’ve created an account and a channel, but the page I’m shown is rather basic. I can’t post my own content, or at least I can’t find how to do it (even though I’ve searched long and hard… but it must be possible, because @ema@utasansh.in  also has a channel there and has posted something… which I was at least able to comment on).

It might be interesting if you want to develop your own application with the ‘Hubzilla engine under the bonnet’, but personally it doesn’t do anything for me (especially as it’s apparently entirely AI-generated).

As I’m getting nowhere with it and can’t see any point or purpose in it for myself… and I’m also wondering how the constant AI support is supposed to be funded, I’ve at least managed to get round it by going to settings/account to delete my account (hopefully for good).

I’ve just tested it in my ddev environment. It works. The filetype is set to text/css.

That’s right, unfortunately… it should be $filename instead of $os_relpath, so


if ($mimetype === “text/plain” && preg_match(“/.css$/i”, $filename))


Is that correct?

I don’t see any chance of a fix for libmagic either. Particularly because the repository isn’t really very accessible.
My suggestion would be:

    // Until here we either used the provided mime type or set mimetype by extension.
    // Both variants are inherently unsafe hence try to find and set the real mimetype before storage.

    if (class_exists('finfo') && is_file($os_basepath . $os_relpath)) {
        $finfo = new finfo(FILEINFO_MIME_TYPE);
        $mimetype = $finfo->file($os_basepath . $os_relpath);

        if ($mimetype === false) {
            $mimetype = 'application/octet-stream';
        }

        // Workaround for libmagic misidentifying CSS files as text/plain
        if ($mimetype === 'text/plain' && preg_match('/\.css$/i', $os_relpath)) {
            $mimetype = 'text/css';
        }
    }

This is harmless, only affects CSS and should sort out the problem.

Right, I’ve managed to get a bit further into tracking down the bug. It’s definitely because finfo() doesn’t identify CSS files as such (text/css), but always as text/plain. I’ve tested this on my local machine and on both servers:

<?php

$datei = 'shtml01.css'; 


if (!file_exists($datei)) {
    echo "Fehler: Die Datei '$datei' wurde nicht gefunden.";
    exit;
}

try {
    $finfo = finfo_open(FILEINFO_MIME_TYPE);

    if ($finfo === false) {
        throw new Exception("Konnte finfo nicht initialisieren.");
    }

    $mime_type = finfo_file($finfo, $datei);

    finfo_close($finfo);

    if ($mime_type !== false && $mime_type !== "") {
        echo "Der MIME-Typ von '$datei' ist: " . $mime_type;
    } else {
        echo "Konnte den MIME-Typ für '$datei' nicht bestimmen.";
    }

} catch (Exception $e) {
    echo "Ein Fehler ist aufgetreten: " . $e->getMessage();
}
?>

In the hex editor, the file starts with ‘68 31 20 7B’, which corresponds exactly to ‘h1 {’. Nevertheless, it is identified as text/plain.

The problem is probably with libmagic, which apparently cannot recognise CSS. BTW: `file --mime-type shtml01.css` also returns `text/plain`. `file` also relies on libmagic.

I then tried to make the file look a bit more “CSS-like” by adding an `@import` statement right at the start. Even with that, the file was not recognised as `text/css`.

JavaScript, on the other hand, is recognised correctly: application/javascript

This is, of course, unsatisfactory and breaks part of the website app’s functionality.

What could be done to ensure that CSS is recognised correctly and entered into the table?

Goethe, 'Faust'. Part One of the Tragedy, 1808. wrote:

"Here stand I now, a poor fool, and am no wiser than before!"

I was able to log in with my account and create a channel to test it out. But now I’m seriously asking myself: what on earth is this? What’s the point of it all?
I can’t and won’t criticise the fact that quite a few things don’t work (yet?)… I realise that this is a project still in development. Unfortunately, the interface isn’t particularly intuitive either (at least not until you know what it’s actually supposed to be).

Is it some sort of “feasibility study”?

So is the aim to determine whether Hubzilla can be run “headless”, so to speak, and to offer a completely standalone UI for it?
The Solidified theme is currently demonstrating convincingly that this is possible. And with Rust, it also seems to be possible… and why not? The main problem with such a UI, which operates completely independently of Hubzilla’s own interface, is that virtually all functions have to be completely rebuilt from scratch. And that also applies to the add-ons. These, too, would have to be recreated. External add-ons would, of course, no longer be usable, unless there were a suitable interface allowing developers to build their own version for the new UI.

Or is this a feasibility study to find out whether an interface can be ‘vibecoded’ from scratch? Well, that also seems possible (at least in terms of what Smarteditor can do now, and what it cannot yet do). The question of whether it’s desirable to create software that has been virtually entirely generated by AI (“It’s over a year’s work, and I haven’t touched a line of code. Not one.”) is one everyone must answer for themselves. For me, it isn’t. But that’s my personal view, and it applies both to creating the software and to using it (which is why I’ll only use this account and channel until my curiosity is satisfied, and then I’ll delete them).

In any case, I’m not quite making sense of the whole thing yet, especially as the site doesn’t really seem to offer any practical benefit at the moment.

I’m not at all interested in looking at the code. I was just curious about the intended licence. An open-source licence would surely be problematic if the code is created exclusively using AI agents.


BTW: I’ve now managed to log in… and I’m at a loss. I’ve no idea what I’m actually supposed to do with an account. What’s the point? What are you supposed to do with the interface? What’s it for?

Yani wrote:

Laozi

Who or what exactly is ‘Laozi’?

I’m a very interested person, you know! 😉😁

So I had a go at creating an account there a little while ago, just to see for myself what all the fuss is about (they do offer remote authorisation, but it doesn’t work). I managed to create the account, but I can’t log in. So my curiosity remains unsatisfied… 😂

Is the system intended to be open source or closed source? If it is open source: where can the source code be found? And what is the specific licence?

OK, so I’ll start with the basics… For those who don’t yet know what a wall post is: the term ‘wall post’ takes its name from the ‘wall’. This refers to the channel stream (also known as a personal timeline or profile on other services). This is the stream containing all the content published by the channel itself. With wall-posting, another user can post directly onto this ‘pinnwand’ (provided you allow it), so that these posts appear in the channel stream. It’s a bit like public personal communication.

This is precisely the feature that forum channels on Hubzilla make use of. Everything that is to be posted in the forum is posted as a wall-post to the forum channel. And anyone who follows the forum channel (i.e. is connected to it on Hubzilla) will now see everything posted there as a wall post in their stream (their timeline), even if they have no direct contact (a connection) with other forum users. Replies to such posts are consequently also distributed to all connections (followers). This makes it possible to run a forum.

A standard forum channel without connections is effectively dead. If you create such a channel using the default channel role ‘Community Forum’, only the channel owner can post there. However, nothing appears in anyone’s stream or timeline. It is an echo chamber. Nobody can post in the forum because the channel role does not allow it. However, if someone establishes a connection to the forum channel, it is brought back to life. The channel role defines the basic permissions for a channel… in other words, what others are allowed to see and do. Wall posting is not permitted. These permissions can now be extended using contact roles (though permissions granted by the channel role cannot be revoked). There is always a default contact role associated with every channel role. As the name suggests, these are permissions that only apply to connections… they have no effect on outsiders or visitors. And in a forum, the default contact role also includes the permission to post on the wall. So anyone who has a connection to a forum channel also has the permission to post on the wall there, i.e. to make posts in the forum. Anyone without a connection can only view the wall and its contents, but cannot post. A connection to the forum channel is therefore a prerequisite for participating in a forum.

And now back to the permissions (which are defined in roles… channel roles and contact roles):

The channel role determines which permissions the channel itself grants. The contact role makes it possible to grant connections (but only connections) further permissions. Every channel always has a default contact role, which varies depending on the channel role. For a channel without connections, this contact role has no effect, as it only applies to connections. You can also create your own contact roles to grant even more or different additional(!) permissions to specific connections.

Here is a table providing an overview of the standard channel and contact roles (CC0):

Image/photo

PDF-Version

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.

There is a fundamental difference between add-ons and apps.

Apps are individual applications that extend Hubzilla’s functionality for the user (channel). Many of them also come with their own interface (though not all… AP, for example, does not) for the user to use them or, in some cases, to configure them. Some apps are part of Hubzilla’s core and are always available for the user to activate (install), whilst many are not part of the core and are made available via add-ons.

Add-ons are installable extensions to Hubzilla’s core functionality. They can make their functionality available to users via apps, but can also extend functionality without any action on the user’s part (in which case they do not come with an app… they take effect for everyone simply by being activated by the admin).

In short: add-ons extend Hubzilla’s core functionality. Apps allow users to activate and/or access core functions or functions provided by add-ons.

Ultimately, only the admin needs to know the difference, as ordinary users do not come into contact with add-ons at all.

I’d understood it to mean that we were talking about archiving individual, complete threads offline. The export function isn’t any help here, as it only backs up your own content.

Joplin is a brilliant application, which I myself use extensively, including with the Firefox add-on. An add-on that integrates with Joplin should be possible, but it would require a thorough understanding of Joplin.

That was my first thought too. The downside is that you’d have to pack the thread’s items into separate files in a suitable format (JSON would be the obvious choice), which would then also have to maintain the parent-child relationship so that the threads are structured correctly when displayed. SQLite would therefore be a good option, as it is simply a text file (albeit monolithic), and you could easily adopt the item’s database structure from the Hub without having to implement a major conversion to your own format within the add-on. Alternatively, it would also be possible to incorporate an export function into the local app to a specific single-file format (which would still need to be specified), should the need arise.