Hubzilla 10.2 brings several important improvements and refactoring under the hood along with the usual amount of bugfixes. Most of the composer libraries have been updated to their latest version for improved PHP 8.4 support. Test coverage has been extended and first steps towards an entity-based code architecture have been taken. Also the Diaspora profile import has been revisited.
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.
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: