harald@hub.volse.no

@Hans van Zijst There's a few things I can think of: Check your xconfig table. I've had issues with it growing a lot for different reasons in the past. Sometimes the real size of the data may be way smaller than the space they occupy on disk, due to frequent updates leading to fragmentation.

You can find some useful queries in framagit issue #1927.

In that case it seemed some indexes had disappeared from the database, which is also worth checking. That caused a lot of duplicate entries in the db.

Another issue I've seen more recently was that the queueworker built up a huge number of jobs. This seems to be due to trying to fetch parents and all downstream comments from messages arriving at the hub somehow. Check the queueworkers page in admin, and the workerq table in the db.

Again, this table is updated frequently, so may be subject to fragmentation.

See framagit issue #1972 for some more background on this.

Other than that. Just see which table are taking up the space in your DB. It should be the items table, and pretty much everything else should be small in comparison. If that's not the case, some investigation is needed.

Good luck!

@𝓒𝓱𝓻𝓲𝓼 https://framagit.org/hubzilla/core/-/merge_requests/2338

@Der Pepe (Hubzilla) ⁂

no, there’s no suitable documentation…

But there are people willing to help you understand. Ask the community (not some slop machine,) and we all learn in the process!

@Jupiter Rowland I don't think anyone is arguing that Hubzilla should not be accessible, but getting it there is work someone has to do.

Demanding that someone else should spend their free time on this will not get us there.

@Saiwal That was easier than I feared. Seems to fix the issue.

Now, to analyze if those headers are secure or not...

@Der Pepe (Hubzilla) ⁂ I think we already cocluded with that. I hope to get time to look into it today.

@Alfred Bühler Thanks for confirming. It seems to be something with my setup that's borked.

@Saiwal Thanks. Definitely on my end, then... Yay, another thing to debug :/

@Saiwal Thanks, probably on my end then. Just to be on the safe side, which version are you running? I'm on 11.4.1.

@Mario Vavti But do we still want it as an addon, or would it be just as well to integrate this into core directly?

@Alfred Bühler Yes, when you know how. WordPress is even easier, but they still benefit from being a "one-click" option in cpanel and other common site admin tools.

@𝓒𝓱𝓻𝓲𝓼 I agree!

Most likely a shared hosting provider will have something like cpanel or similar management tools installed. Which will make things like scheduling tasks and stuff easier.

Perhaps making some sort of cpanel-integration would be a good investment.

@𝓒𝓱𝓻𝓲𝓼 There's an intro to crontabs and scheduling tasks here: https://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Scheduling_Jobs

The FreeBSD Handbook also has a decent section on scheduling and cron here: https://docs.freebsd.org/en/books/handbook/config/#cron-periodic

(The periodic system I believe is particular to FreeBSD.)

While there's no need to be an expert to host a Hubzilla server, a bit of basic unix knowledge is very useful :)

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.

@Beni Grind ~HB9HNT To not have written PHP for 20 years, I find it fascinating that you use constructs introduced in PHP v8.0 :)

I think it looks good in general. A few nitpicks, but nothing major. I leave the final judgement to Mario :)

@Beni Grind ~HB9HNT

I should rather fix this and make Hubzilla more IPv6 capable.

That would be great! Ideally it should not have to care which protocol version it's using, but that would mean getting rid of implicit assumptions that are only valid on IPv4.

@Der Pepe (Hubzilla) ⁂

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

How about just "Mute"?

Adding "Ignore" and "Block" to the menu items of connected channels is trivial. Adding the same expiration feature that Superblock now has is also doable. If we move all this functionality to Superblock, it would almost come by itself. (I think...)

The question is: Do we really need all three options? "Mute", "Ignore" and "Block"? Or would it be enough with just "Ignore" and "Block"?

Do we really want that posts and interactions posted while "muted" should reappear when the mute expires?

@*_jߍyrope

To me, a block is a block. That means i don't see their content, and they don't see mine.

Whereas a mute would let them see my posts and eventually even let them like & comment, however i wouldn't see any of their posts.

I'm open to change how we name things if that can make it less confusing. Exactly what the names will be is less important as long as we agree on, and can describe how the different features work and fit together :)

@Der Pepe (Hubzilla) ⁂

4. If I set a superblock on a third-party channel (which is not a connection), I no longer see its posts, but it also no longer receives my subsequent posts.

How is this different from when the third-party channel is not blocked by Superblock? They will still not receive your content.

In both cases they may still see your content if your post is public, and somebody else on their hub/instance is connected with you, or when you interact with a post from someone they are connected to.

Superblock should afaict not interfere in any of those scenarios.

@Mario Vavti

I can imagine some sort of soft ignore (current superblock behaviour) and hard ignore (current contact ignore behaviour)

That's an interesting option.

As mentioned earlier, my current plans for the next Superblock version is to block incoming activities, so that they will no longer become visible again when the block expire or is removed.

From your feedback here it seems we should think more closely about this before going that direction.

@*_jߍyrope There's probably some subleties that need to be ironed out, but from my understanding it more or less is.

@Jupiter Rowland It could also be that the jsonld library we're using us not up to date with the latest standards. JSON-LD is quite cool when used to it's fullest, but it's also a pretty hairy standard to parse.

Knowing where these payloads come from may help debug the issue, but not sure if it's worth it if it's only from this site and it's using unstable software.

@Alfred Bühler

First off, blocking infoseek.exchange under admin->security didn't seem to work. I had to block it via the .htaccess file. Then I recognized the trailing '/' as part of the host name! Adding this, Hubzilla's blocking works;

That seems like a bug to me. We should be able to match against only the domain name.

BTW, I apologize for the double post. Obviously my subscription to this channel is broken. I no longer see any forum posts in my stream.

I had that happen to me to at some point. I think somebody with admin rights to this channel needs to go in and see if you're marked as unreachable or something.