Hubzilla 10 is here and brings conversation containers a.k.a. FEP-171b along with performance improvements and some code refactor. Here are some of the most notable changes:
Implemented filed items in mod HQ
Deprecated jquery in favor of vanilla javascript in some core components
Implemented possibility to link directly to a month, week or day via URL fragment in mod cal
Toggle aside in mobile view if a message or notification is clicked
Various bugfixes
For a full list of changes in this release, please see the changelog.
A big THANK YOU! to all the contributors and everyone who supports Hubzilla and its development.
#Hubzilla is a powerful platform for creating interconnected websites featuring a decentralized identity, communications, and permissions framework built using common webserver technology.
If you wish to participate in the RC testing, please git checkout 10.0RC your core and addons repositories. The status of the RC testing can be followed in this wiki.
Please refer to the git history for the changes. A detailed change log will be provided with the release announcement.
You are welcome to contribute fixes in form of merge requests and bug reports for issues you might find at the Hubzilla source repository.
@julian i get your point. But maybe in this case the trust question is more philosophical: do we want to trust the one we have the connection with - in this case the context owner or do we want to trust the author with which we are not connected at all and whose messages might be forged too - even with proof?
@silverpill How does it check that the user is logged in? Does it present a login form? The user has to be logged in at his home instance before starting an OWA attempt to another instance.
What URI is being put into actor field of activity, and what URI is being put into keyId parameter of HTTP signature? Actor is the remotely via OWA logged in actor., the HTTP requesti is signed by the thread owner.
@silverpill in regard to authentication: isn't it sufficient to trust the sender at last? In this case the context owner?
Let's assume this situation: an actor is remotely authenticated at a server via OpenWebAuth and comments on a post there. No proof can be added and the object is not yet available at the actors origin server. In this case the message will be rejected allthough its authenticity is verified.
I'm still slightly in favor of that solution because it is more efficient and keeps conversations synchronized across servers. And Hubzilla will support it soon too :winking_face:
@dansup as mentioned, i am not the one you need to talk to. I am just observing how things are currently evolving and worried that fedi will end up with a number of incompatble implementations of a imo crucial feature.
@dansup from my point of view, implementing a protocol requires a very different skill set than developing a protocol. So no, i do not consider myself a protocol developer.
As you know, comment policy was not part of the original protocol as released in 2018.
@dansup i am not considering myself a protocol developer. There are people with decades of experience like @Mike Macgirvin 🖥️ or @silverpill who has some great ideas too. Things are usually discussed on fedi or socialhub afaik.
I would have wished for a broad discussion among multiple projects (including a view on their history) instead of "look, here is our implementation". That's all.
Embed this noticeMario Vavti (mario@hub.somaton.com)'s status on Thursday, 18-Jul-2024 18:30:41 JST
Mario VavtiHubzilla 9.2.1 - Fix fatal error if gd function image{jpeg, png, webp}() did not exist for some reason - Add missing pdl for mod import - Escape queueworker json data - Fix missing object when repeating own posts - Improve display of system notifications in relation with page reloads - Add possibility to only display system notifications with notifications widget - Fix layout issue with socialauth addon - Save a db lookup if we have just reset notifications in sse addon - Fix php error if attachment was an empty string in pubcrawl addon
Hubzilla 9.0.2 - Fix buttons in event viewer - Fix some PHP warnings and errors - Fix issue when inReplyTo field is an array - Fix possible queueworker crash - Fix missing pdl file for mod home - Reduced default directory result set - Fix fatal error in likebanner addon - Fix fatal error in hilite addon
@silverpill i have received your like and it was relayed from here to my other contacts. The fact that other hubs may reject them with 409 is because they are supposed to receive the like relayed from my channel in case they are accepted here.