harald@hub.volse.no

@Mario Vavti I toyed a bit more with this, introducing the abstract Entity base class that does the actual db interactions.

See commit 8a79b5a3.

It's rough, but should give a general idea. I think it's possible to take it even further, making the entities themselves more declarative, apart from the actual functionality they bring.

@Mario Vavti Yeah, I would like to see some more separation there. I imagine it would be useful to split common stuff into a base class and/or traits as we see fit.

I think which parts to split out, and how will become more obvious as we add a few of these classes.

Also, I forgot to mention. I completely disregarded error handling in the example to keep it simple and focused on the main issues.

Example entity: Addon

MR: https://framagit.org/hubzilla/core/-/merge_requests/2315

This is just an example, as a base for further discussion. I chose to implement an entity class for the addon table, because it's small, and relatively easy to reason about.

I have ignored some of the columns of the table, as they seem to be unused.

A few things to note:

• I've made the constructor private. This prevents the class from being instantiated by outside code. This may not be correct for all entities, perhaps not even for this one, but it keeps things simple by giving us more control over how the constructor is invoked.
  
  Instead of constructing the object directly, they are created via the static initializer functions. I've just included a couple of examples, but more can of course be added.
  
• The object properties are declared as readonly, this reduces the need for "getters" while keeping the class simple. It may seem a bit strange at first, but in cases where a changed object is needed, just create a new one instead. Also remember the lifetime of an object is for the current request only, at maximum.

Other than that I think it should be fairly straight forward. I've added a few helper functions to make things a bit more readable, and reduce code duplication.

The basic premise is that all interaction with the database table should go through the entity class. The calling code does not need to know how it's stored, or even that the data is stored in a database.

Likewise, the object has all the information needed about itself, as well as the methods needed to interact with it or manipulate it.

Once constructed the object is valid! There's no need to check the validity of the object in code that receives one. This internal consistency should be maintained by the object itself. This is part of the reason we make the properties readonly, or private if readonly is not a viable option.

Looking at the other entity classes defined so far, they do none of these measures. Properties are public, so they can be manipulated by anyone without the object itself not even being aware. They provide getters and setters, but don't do any validation in any of them, and the same with the constructor.

I hope this can be a useful starting point for the discussion, despite it's not the most interesting we would need.

@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.

@Poul Udbye Pock-Steen Ok, I have not looked into the attachment name yet. I'll see if I get time tomorrow.

I've made a merge request that I think will fix this issue here:
#^https://framagit.org/hubzilla/core/-/merge_requests/2301

@Poul Udbye Pock-Steen Ai, that's not good... I'll have a look.

@Der Pepe (Hubzilla) ⁂ Terms can be confusing, but the two attributes have different meaning for a reason.

The alt attribute is the one being used by screen readers to provide image descriptions to blind or visually impaired people.

The title attribute however is a global attribute meant to provide additional info about whatever element it's attached to. This is typically shown as a tooltip when hovering over the element.

Most screen readers will fall back to the title if the alt attribute is not present, but it's not safe to rely on that. The attributes are distinct and has a different purpose for a reason.

@Der Pepe (Hubzilla) ⁂ are you sure about that?

The example from @𝓒𝓱𝓻𝓲𝓼 above does not set the correct html alt attribute:

<img class="zrl" loading="eager" style="width: 100px; height: 200px; max-width: 100%; cursor: zoom-in;" alt="Bilde/fotografi" title="Alt Text" src="https://klacker.org/photo/cd747cd9-3f05-42cd-94cc-91c7368c5a18-2.png">

Don't confuse the alt attribute with the title which is the one that pops up when you hover over the image.

@Poul Udbye Pock-Steen In which text field do you observe this behaviour?

To actually get an alt attribute in the generated html, use something like [zmg ... alt="a bleak outlook over a nascent moon"]

There's a few other attributes supported as well. Here's a complete list:

• alt="Alt text"
• title="A title"
• width="42" with in px.
• height="66" height in px.
• class="myclass otherclass" custom CSS classes.

In addition there's a legacy format still supported:

[zmg=42x66 float=left alt=some alt text at end]

Note that the order of the attributes must be exactly like this in the legacy format. Both the float and alt attributes are optional, but must come in this order if present.

Note also that the float attribute is not directly supported in the new format, but can be simulated by setting a CSS class instead.

I think we should probably add back the float attribute directly in the new format as well.