pepecyb@hub.hubzilla.hu

Hast DN.

Hubzilla Support Forum wrote:

util/add_widget_repo

I had the same problem recently.

Please note that the repository structure for your widget is as follows before you integrate it usingutil/add_widget_repo:

abu/YourWidget/YourWidget.php

The widget must be located within your repository directory in a subdirectory that has the same name as your widget file itself. If you simply place it (as described in the old documentation) in the repo directory itself, the system will not be able to find it. Hubzilla looks for widgets in `widgets/<WIDGETNAME>/`, and the util script will only create this structure if your repo is organised in the same way.

Well, now you can log in and create a channel… 👍

OK… that’s one way to search. But it’s not really for the average user. And all the hubs in your example are closed to new registrations.
Feel free to create an account on forte.hubzilla.net!

Yes, forte.hubzilla.net is my hub (open for registrations) and my channel there is called Blue Nomad. 


On Fediverse Observer, you can actually find quite a few Forte hubs. But without the option to register, that doesn’t really help either.


I don’t use Google. But tell me, how (using which search term) did you search? Probably not just ‘Forte’, because you’re hardly likely to spot the hubs amongst all the medicines 😉😂.


My hub runs on YunoHost… and at the moment, the update frequency is going relatively well too.

@Jupiter Rowland


I’ll throw in one more thought here about Forte’s nomadic identity: it’s theoretical!

Yes, it’s supposed to work. But I don’t know myself whether it actually does. Even though I run a Forte Hub myself.

Why?

Because there are probably very few Forte Hubs; you simply can’t find them (in any of the usual Fediverse databases). Because you can search for them (if you know where and how, you might even find a few, but virtually none where registration is open).

So, with my Forte channel on my own Forte Hub (which, incidentally, is open for registrations), I have a nomadic channel, but simply no account where I could clone it (even just to test it out).

For me, therefore, the nomadic identity is purely theoretical.

I’m not sure, but personally I’d give 

?question

a go.

@kubaurbanowicz@zotum.net 

Especially when it comes to a website for an NGO, Hubzilla would be the first choice because it offers CMS capabilities. And it’s extremely resource-efficient, so it doesn’t place heavy demands on the server (I imagine it’s comparable to Forte).

I’ve also written an article on this (unfortunately only in German: Mit Hubzilla eine Organisations-Seite im Fediverse anbieten), in which I created a website using an NGO as an example (one that actually existed and whose team I was involved in). If you have any questions, please feel free to message me via DN (in English, if you like).

@Hubzilla Support Forum

@kwj@hub.hubzilla.de⚪🔵⚪🟡

To do this, you can edit the channel in the ‘Connections’ app (Connection Editor – accessible via the small pencil icon). In the Connection Editor, select ‘Ignore’ from the ‘Contact Tools’ menu (bottom left).

@Ferret

Good to know. Maybe it's ass software, but if it isn't malicious I don't see the reason for tearing into it?

I’m not trying to slag this off at all; rather, I want to point out that all the features which Bonfire presents as new and of their own invention have actually been available for well over ten years in a very well-developed piece of software. Potential users should be aware of this and perhaps take a look at Hubzilla from this perspective, rather than waiting for a piece of software that promises a lot but is still a long way from being truly useful.

@Jupiter Rowland @Ferret

Since 2012: "Hubzilla, formerly Redmatrix, formerly red": Groups (forums) and tools for collaborative organisation

Schon seit 2012 „Hubzilla, formerly Redmatrix, formerly red": Gruppen (Foren) und Tools für die gemeinsame Organisation

😉

@Harald Eilertsen

Personally, I don’t need a mute function that brings back the posts that were previously hidden once the mute is lifted.

It doesn’t really seem necessary either, because when you mute something, you do so for good reasons… you don’t want to see those posts. If you lift the mute, most users will simply assume that applies going forward.

Ultimately, therefore, an ‘Ignore’ and a ‘Block’ option would be entirely sufficient, provided they can also be applied to third-party channels and the lists can be managed via the add-on.

@Mario Vavti

@Mario Vavti In that case, it would make sense to rename the add-on to ‘Supermute’ and change the menu option to ‘Mute from channel’.

Perhaps, however, when it concerns connections, the menu could be expanded to include ‘Ignore’ and ‘Block’ to avoid having to go via the ‘Edit connection’ editor (although I don’t actually find that route particularly cumbersome).

@Harald Eilertsen

@*_jߍyrope

That’s exactly what I wrote. A superblock is a ‘supermute’ when applied to connections. But a Superblock is a ‘Superblock’ when applied to external channels. That’s why it would make sense not to display the Superblock menu item in Connections, or to extend Superblock so that, when applied to Connections, it also blocks or unblocks those channels within the Connections.

As it stands, it’s a bit confusing for the user, although I myself would never think of blocking a connection with Superblock, as that’s precisely what the function in the ‘Connections’ section is for. In my view, the most sensible approach would be to hide the Superblock menu item for channels you’re connected to. After all, Superblock exists precisely so that you can block third-party channels (with which you have no connection), which isn’t possible with the connection block. I don’t think implementing the menu suppression would be too complicated either.

@Harald Eilertsen

@*_jߍyrope

should be called Supermute, right?

No, Supermute only works for existing connections (which isn’t what it’s designed for). It blocks external channels (I tried it out today).

A mute function for external channels would probably need to be implemented separately.

@Hubzilla Support Forum

Block blocks the connection in both directions. The contact will no longer receive your posts, and you will no longer receive theirs.

Ignore is similar to ‘mute’ on other services. Whilst you will no longer receive their posts, they can still receive yours.

@Harald Eilertsen @𝓒𝓱𝓻𝓲𝓼

I’ve just been looking into this topic in more detail, particularly in relation to Mastodon.

When you attach an image with a caption on Mastodon, both the `alt` and `title` attributes are set to that text. This means that when the image is imported into Hubzilla, the text description is also displayed as a title pop-up.

If you add a description to an image on Hubzilla by placing it between the [zmg][/zmg] tags (the usual method), i.e.

[zmg=<IMAGE_URL>]<IMAGE_DESCRIPTION[/zmg]

Hubzilla behaves in exactly the same way as Mastodon, inserting the description using both the alt attribute AND the title attribute.

When this reaches Mastodon, the image description is also flagged and displayed accordingly.

If, on Hubzilla, you insert the image description within the [zmg=] tag, the image description is added as the alt attribute, but no pop-up appears because the title attribute is not set. On the receiving end, e.g. on Mastodon, the alt text is flagged and displayed.

So, if you want an image description on Hubzilla not only to be present but also to be visible as a pop-up, the “usual method” is the better choice. If it’s really just about the image description and you don’t want a huge pop-up to appear for “epic image descriptions”, then use the option with the alt attribute within the [zmg=] tag.

@Harald Eilertsen @𝓒𝓱𝓻𝓲𝓼

I’ve just had a look at the source code of my test posts. AND: Yes, the `alt` attribute does what it’s supposed to do and inserts the `alt` attribute correctly into the HTML.
It was simply a misunderstanding.

@Harald Eilertsen @𝓒𝓱𝓻𝓲𝓼

Ah, OK... we’re using different terms here.

You mean the actual HTML ‘alt’ attribute, which contains text that is displayed if the actual image cannot be shown. I think you can set it correctly using ‘alt=’ in Hubzilla. So it will work after all.

However, by “alttext” we actually mean this pop-up text, because that’s what’s now commonly used in everyday language for image descriptions. And for that, “alt” doesn’t work – only “title” does.

A communication problem due to differing definitions.

It really would be better not to write or say “alttext” for image descriptions, but to actually use “image description”.

Have a look online: there are now quite a few “alt-text bots” that are actually “image description bots”.

@Harald Eilertsen I’ve just finished a test session… with ‘x’ variations.
Based on my tests, I’ve found that the ‘alt’ attribute has no effect whatsoever, at least on my hubs.
The ‘title’ attribute must be used as the alt text. That way, it works.

@citc I’ve tried it (on two different hubs, both running 11.2.1). I haven’t been able to reproduce the problem so far.

Perhaps someone else is experiencing the same issue. I’m afraid I can’t be of any further help.

@Hubzilla Support Forum @citc

What do you mean by ‘share’?

Did you want to share a public post from Channel Y's stream to Forum X?

That works (just tested it).

“Sharing” as ‘posting’ also works with Wall-to-Wall, Privacy Tool and @! mentions.

@KlausR Ah, OK. So the problem was that the poll was sent to a specific privacy group (i.e. to the connections within that group).

By design, that doesn’t work either, as a guest account doesn’t have its own stream.

Question for @Mario Vavti  : Which permission actually applies to polls? I think it should be ‘Can comment on or like my posts’, correct?

@Ema エマ Yes, it needs to be written in.

@Hubzilla Support Forum @KlausR

By ‘group’, do you mean a forum channel?

I’ve just tried it out using one of those, and it really isn’t possible to take part in a poll like that with a guest access token (posting comments, on the other hand, works).

I’m not sure, though, where you’d need to go to enable guest access to polls separately.

There is no separate permission for this in the roles.

For the test guest access, I created a ‘Standard-Plus’ contact role that allows everything except uploading to the cloud, editing wikis and web pages, and administration. Even with this contact role assigned, the guest was unable to take part in a poll.