cover photo

Hubzilla Development

 Königsberg, Russia,  last edited: Mon, 24 Sep 2018 18:34:26 -0400  
!Hubzilla Support Forum !Hubzilla Development

I found that #Hubzilla (and seems a lot of other #PHP software) have issue with #MySQL 8. In my case this is a latese release 8.0.12.
According documentation MySQL changed Preferred Authentication Plugin on new caching_sha2_password type. It causes authentication errors like

mysqli_real_connect(): The server requested authentication method unknown to the client [caching_sha2_password]
mysqli_real_connect(): (HY000/2054): The server requested authentication method unknown to the client

To avoid this replace authentication scheme for users on mysql_native_password by

ALTER USER 'user@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

Until software will not be updated to work with the new password schema will be a good idea to leave the old driver on by adding default_authentication_plugin = mysql_native_password in [mysqld] section of MySQL configuration file.
Hubzilla doesn't care about the SQL authentication method. It is opaque to the application and handled by the PDO mysql driver.  So this is suggesting that the PDO drivers also need updating if you decide to upgrade to MySQL8.
I'm now on PHP 7.2.10 and I ran into this problem with both Hubzilla and phpMyAdmin for example. Probably, some additional settings are required on PHP side.
  last edited: Mon, 24 Sep 2018 15:44:29 -0400  
!Hubzilla Development !Hubzilla Support Forum

A little tip to make tracing what's going on with users perhaps just a little easier - or, if you're like me and have several browser windows open, it becomes difficult to trace what each one's doing and can be quite confusing. This also irreversably obfuscates potential identity information and may be handy for GDPR compliance.

1) Change your MAIN logging string to use a custom MD5 hash (this usually resides in nginx.conf:

log_format main '$remote_digest - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

2) Set the $remote_digest variable in your server configuration

set $mkdigest '{SomeCustomSalt} $remote_addr $cookie_PHPSESSID';
set_md5 $remote_digest '$mkdigest';

3) Apply the main logging string to your logs

access_log /var/log/host-access.log main;

You can create a similar string for the error logging.

You will not be able to identify IP addresses anymore, but this will actually be MORE HELPFUL in looking at your logs. Imagine a family all sitting behind a NAT router in their home. There would be no way in the log to identify which is which! But with this, each device even on a NAT network has it's own tag - allowing you to [strike]track them independently of[/strike] [underline]distinguish them from[underline] one another.
You can usually identify the remote channel, as it's provided as a string in the url.
That way you can often link the hash with a channel and a channel is a login.

Yes, "default" logs are bad. You add additional logging, as you include a random number to identify multiple people using the same IP. Even if you don't directly log that IP, your logging is more specific than an IP, thus you increase the tracking above the default levels.
You can usually identify the remote channel, as it's provided as a string in the url.
That way you can often link the hash with a channel and a channel is a login.

Removing arguments from the log and logging only the URL itself (not the additional query string data) mitigates that issue (and is the one I was referencing as the potential to infer).

It seems your caught up on the fact that I used the specific term "track," which was a loose way of speaking and described the action of following a specific session which, though is tied to an individual, is not directly identifiable with the "data subject." I agree that some level of further mitigation is necessary in order to pseudononymize the data for full compliance, thus why my specific statement was, "may be handy (i.e., helpful) for GDPR compliance". This wasn't presented as a "silver bullet" or a full solution, it was presented as a helpful tip and a pointer in the right direction.
Of course, if you want to be fully compliant, you simply won't run a web server that others access and you'll rely on the big data brokers like Facebook, Google and others who openly admit they mine your data and force you to accept that fact or go without their services. That's an option also.

  last edited: Mon, 24 Sep 2018 10:34:27 -0400  
!Hubzilla Support Forum!Hubzilla Development!Hubzilla Support Forum
!Hubzilla Support Forum!Hubzilla Development

I find that the structure of the hubzilla support form is not very efficient. Many questions are asked over and over again and quit a lot of time is lost by answering this question over and over again.
If questions and answers were tagged and if there would be also a given poll of tags to choose from - the search for answers would be much better.

If someone wants to post in a forum he/she should be forced to tag the post. This could be a setting which the admin could activate  - or could a new plugin do this?
forces to categories a post would work as well ;-)

  last edited: Fri, 21 Sep 2018 06:37:44 -0400  
Here is the deal:

Every app (a.k.a. module) with settings will have its own settings page accessible either from the app store and from the module UI itself (settings icon beside the app name in the panel).

This will deprecate the additional features and addon settings.

I think this will ease most of the usability issues with settings we have.

If you have any objections, speak now or be quiet forever.

!Hubzilla Development !Hubzilla Support Forum
 from Friendica
No. From yesterday.
Pulled again. Ah! Much better. :-)
I agree : exemple the question Start calendar week on Monday could be on the calendar not on channel setting. That will be one less paramater. This is only my last example but you can find a lot like this.

Is anyone maintaining an up to date installable version for andhub anywhere? Did a quick search and couldn't find one. I know there was one somewhere because I have it installed! Lol.

!Hubzilla Development !Hubzilla Support Forum
Thanks a lot for the link, following now!
Hi, please consider sharing a Nomad folder which we can check for the latest versions of the app. This could be done via a Nextcloud shared folder or Hubzilla webdav share afaik. Cheers!
  last edited: Sun, 23 Sep 2018 01:47:17 -0400  
I already did share a nextcloud folder.
You can find it joining

Or by nextclod directly

Will add files directly on hubzilla as soon as i have spare time. ;-)
!Hubzilla Development is developing ActivityPub support for sharing audio and video streams, plus allowing Funkwhale users to be followed via ActivityPub. Discussion of integration is in the PixelFed developer Github and Funkwhale Gitlab.
I hope they just use the normal 'Announce' activity which is used for sharing things instead of a new word that isn't in the ActvitivyStreams vocabulary. I've added a note on the funkwhale issue. Will need to double check but if they don't overthink it, everything should just work in Osada.

!Hubzilla Development
I posted elsewhere but THIS is probably the place (I am aka @afterpod admin (rick) ).

a new podcast about the Fediverse hosted by

A knowledgeable person who could LITERALLY SPEAK for Hubzilla could probably get booked for a future episode pretty easily. Probably someone in this forum.

As I see the lay of the land - APPS can be enabled on the server and installed by individual channels, but there is no "middle ground" that allows Apps to be installed on the server and only installable by SOME channels (based on either channel or account restrictions). (maybe I'm missing something... if so, I'd be grateful for a pointer)

I started working on some hooks to make it possible, but ran into an issue looking at the APP synchronization code that causes me to think a solution needs to be more widely discussed.  My work so far simply hides the ability for a user to install an app on on their channel by filtering what is/isn't allowed on the channel app install screen based on a field in the SERVICE_CLASS array.  It is thought to later expand this to a variable in pconfig so that the CART system could be used to allow paid access to specific apps.

I know it needs to go further, but I'm having trouble getting around how to deal with the scenario of a user cloning their channel on another instance and installing/enabling an app on the 2nd instance and having the app synchronization automatically enabling it on the original instance - which - if I read the code correctly - is the likely behavior if the hub itself has the app enabled even if the individual channel doesn't click the "install" button on their channel settings.

Then there's a second issue with regard to hooks.  As far as I can tell, there is no central "app enabled" setting on a per-channel basis that blocks an app's hooks and code from running if it's enabled hub wide even if the app isn't installed on a channel itself (I've run into the scenario of hooks triggering for channels where the app wasn't installed more a couple of times during development).  

So far I've resorted to creating an "enable" (pconfig) setting for the app(s) I've created.  Any  hooked functions that are triggered from elsewhere in the system do a check against the pconfig variable to make sure the app is "enabled".  The problem is this solution seems wasteful (every hooked function must run the check every time it's triggered).  And, it doesn't lend itself to the possibility of a hub admin blocking/enabling an app on a per channel or per account basis (for example, from the SERVICE_CLASS settings or even being able to enforce some sort of subscription payment structure for apps) but still having it enabled server wide for use by other users unless the app is specifically coded to behave this way (i.e., the app itself checks SERVICE_CLASS or some setting set by the cart system or some other settable variable).

I admit, I may be entirely missing something obvious in the code - but I don't see the current code permitting these scenarios.  At the same time, I see an implicit intention to support such things.  Even if it is just me reading into the project my own thoughts and desires, it seems that these would certainly be features that would help immensely hub admins who want to more completely "hide" functionality from some users and open it up to more advanced users (or paying subscribers).

There is no "silver bullet" to fix all of these at once.  Any solution will lead to some level of change in the core beyond adding a hook or two or even a few.

Has anyone already thought through a potential solution?  I have some ideas, but I know there are others who know the code better than me.

I think it'd be helpful to have a similar system that allows the locking of certain features generally and default settings on an account (or preferably, both an account and a per-channel) basis - though, until we get to the end of the "appification" process, I think that should wait.
At the hook level itself, we simply need a binary "yes/no" do or don't run this hook, right?  So what about the following in call_hooks() right at the beginning of the foreach loop:

$checkhook = [
if ($name != 'permit_hook') {  // avoid looping
        if (!$checkhook['permit']) {

I'm not sure the copy needed to include $data would be worth it - unless it's still true that variable copies aren't actually created until modification (cxref: ), in which case it's a no-brainer that you'd want to add it.

Then, from a "core" vantage point, how someone wants to implement hook permissions is out of our hands.  For some addon's (probably the great majority of 3rd party developed apps), it would be an easy check because the needed state (channel references, observer references, etc) will be known before the hook gets triggered - If you want to exclude an addon wholesale, just check the filename of the hook:

if (strpos($checkhook['hook'][0],"addon/{$addonslug}/")) {
        if ( {{ CUSTOM HOOK LOGIC }} ) {


This won't catch hooks added by hook_insert().  But a similar if statement could be made to check the function name ( $checkhook['hook'][1] ) against a list of hooks (or class names) you want to exclude.

Of course, the majority of 3rd party addons can probably be handled using the module_loaded hook in \Zotlabs\Web\Router::__construct().

Users of these hooks would need to know the details of the modules they want to filter out - but that would be "their problem" to figure out.

Am I missing something?
That's fine if you just want to allow or prevent a hook. I was only mentioning that there isn't a lot of context. I don't know how you could allow the hook for one person (say due to their service class) and deny it to another per this statement(*) because the hooks themselves don't know who is accessing them.

What I'm looking for is a standardized way to enable/disable the running code related to individual addons on a per account/per channel basis

You may be able to get away with session information (local_channel(), remote_channel()) but this will only be applicable to a very small number of hooks which are invoked via web access. If you're ok with that limitation, fine.
Ah, I see what you're concern is. THAT is the ideal. Clearly we aren't there at this point - so a method customized by addon is the best I think we can do. I think the proposed solution provides the flexibility to facilitate a standardized solution in the future - while making the aim and goal possible (if a bit arduous) in the short term.

As for context on addons that need to at least BEGIN running before there is enough context to make a determination, I think this solution allows someone to build a traffic director that could gather that context as it goes. Of course, you'd have to study the hooks and the data structures for the plugin(s) you want to allow/prohibit and you'd only be able to make a determination after the hooks that build the context needed have triggered (basically you'd need to whitelist some hooks and then blacklist others if needed after you had enough info to do so). But I think this provides the flexibility to do so without admins needing to adjust the addons themselves.

And, with the structure there and the aims and goals in the open, maybe addon authors in the community would consider structuring their addons in a way that makes needed criteria easily available in a standardized way in the future.
  last edited: Mon, 17 Sep 2018 16:01:37 -0400  
!Hubzilla Development
cc at !Zot universe NEWS

Socialhome project is interested in adopting the Zot protocol as mentioned here on their Gitlab or discussed on the Github mirror here. Looks like they will be exploring it once ActivityPub support is completed.
If you added Zot support to your federation library, this would allow any app using Python/ Django (eg GetTogether) to also add Zot support, by using (and hopefully contributing to) your federation library.

That would be awesome! Lots of interesting Django apps around.
!Hubzilla Development !Hubzilla Support Forum
Libranet SupportLibranet Support wrote the following post Sat, 15 Sep 2018 07:46:20 -0400

Hubzilla - carddav and caldav update

Hello Hubzilla users on,
there was an update to the 'cdav' stuff ? It has been "appified".
WARNING: if you use caldav or carddav from a client or the webinterface you will need to enable those apps to make things work again

#hubzilla #caldav #carddav

!Hubzilla Cart Addon !Hubzilla Development !Hubzilla Support Forum

@Mario Vavti mentioned that we can hopefully expect 3.8RC to come the end of this month. I'd at least like to make sure by then that all the existing functionality of the cart system is working correctly. I've pushed a few UI tweaks in the last week or so. But I haven't heard any real feedback. If you are running the DEV branch of Hubzilla on a server and could do some testing, it'd be greatly appreciated. I'm going to try to get some docs of how to do some things put together soon as well, but I'd kind of like to know what people can/can't figure out on their own.

So any feedback would be helpful. I'm going to be honest - I'm not a UI guy. Any GOOD UI elements are probably Mario's doing trying to make things look better (THANKS MARIO!).

What SHOULD be working:

1) The TEST catalog
2) Manual catalog items (as if you were going to take orders on line but do all the back end processing manually)
3) Hubzilla Services (add buyer as connection, add buyer to privacy group, and for hub admins, change service_class of buyer's account)
4) Subscriptions (extend length of subscription on subsequent purchase, auto expiration and "rollback" of Services if using the Hubzilla Services module)
5) Paypal payments
6) Auto-fulfillment upon Paypal payment
7) Manual payments
8) "My Shop" admin tools to fulfill and take notes about an order.
9) "Shopping cart" functionality
10) Order button widget for use in web pages and other areas where widgets are enabled.

!Hubzilla Development
First of all thanks everybody who are contributing in this wonderful project.

We are using Hubzilla to build enterprise educational application. Hubzilla acts as underline engine to provide social networking features in the enterprise application mentioned. Our web application use REST api provided by Hubzilla for the communication. We have some questions on Hubzilla API and hope some of you may point in to correct path.

1. API to create account, profile and users in Hubzilla ?
2. API to create or update profile pictures of a channel ?
I am happy to hear that you are building this application. I've often thought educational institutions were a perfect fit for Hubzilla because independent school systems could use it to share data and enjoy social networking capabilities without sacrificing their independence or autonomy. Due to the limited resources with which Hubzilla has been developed, a robust API for a generalized client has not been a priority. There are plenty of hooks in place to do almost anything you need, but you will likely be part of the development of the API endpoints that your project needs. This is an ideal way to give back the the Hubzilla project as you benefit from all the work that has gone into it over the years.
1. API to create account, profile and users in Hubzilla ?

You could do that through the LDAP auth plugin. Not that easy to setup, but the LDAP ecosystem would open many ways to automate user-creation.

The goals:
  * Maintain current security regarding content restrictions and content filtering in existing apps/modules.
  * Maintain/allow privacy settings and restrictions on stored items of existing modules/apps.
  * Allow addon devs to store and retrieve arbitrary unfiltered data for use by their addon.
  * Allow arbitrary unfiltered data to be assigned privacy settings and restrictions consistent with other modules/apps.
  * Provide a mechanism for unfiltered addon data to be cloned to channel clones. (Nomadic identity remains in tact even if the addon is not installed and running on the clone's hub - the data will not be used without the addon (unless it's accessible through the cloud/file interface), but it will exist in the even that the addon is installed and activated in the future).

Proposed solution:
  * A standardized interface for addons to track/access and save and retrieve data in the existing attachment file store as an arbitrary data store.

Implementation suggestion:
  * add an "attconfig" table (k/v store) and utilities for items in the attach table that mirrors pconfig, iconfig, abconfig, etc. for storage and search of addon-specific attributes.
  * add an "addon" column to the attach table to track the originating addon
  * implement an interface for the content column (insert/update) (attach.os_storage = 0) to store arbitrary data in the database
  * implement an interface for os file contents (attach.os_storage = 1) for addons that may want to allow WebDAV file based updates to app data.
  last edited: Thu, 13 Sep 2018 17:16:01 -0400  
From my remberance of the code, both item and item_id are cloned, you are correct.

No apology needed for talking about your project... It's great to hear how others are using the platform! It's good for ideas and it's good for the devs to know others are making use of what they have created!
It's good for ideas and it's good for the devs to know others are making use of what they have created!
I do not much comment usually but read the dev and support forum like a newspaper every day. It is very interesting to follow the thoughts. It helps me to understand better whats going on under the hood of Hubzilla
Investigating and thinking through implementation....

I'd rather not muck around with the core. Creating AttConfig appears it will be a nightmare - and I don't think sending whole file updates with every meta data change is reasonable. Now I'm thinking of a completely different implementation - but with the same result - feedback would be appreciated.

Instead of using a new "config" table for meta data and needing to build a new synchronization structure, what about using the current pconfig to store file metadata for the files?

I'm thinking: structure the 'category' something like appfile:{appslug}:{attachmenthash}. Then the app can have full control over the 'key' and 'value'. This has the benefit that PCONFIG is already nomadic aware. And updates to meta data will not trigger the added network traffic of a file synchronization.

The only complication I can see is the possibility of file deletion while leaving meta data. But I think a hook in the attach_delete() function could easily remedy that.

This means no core coding (except for the additional hook), and should still permit an implementation of the intention of arbitrary object/file storage for apps.


M. DentM. Dent wrote the following post Thu, 13 Sep 2018 00:33:03 -0400
Withdrawl of PR 1270 (various Hooks)

Just a note withdrawing PR 1270 - some notes are in the PR discussion itself.

1) Hook to change App::$page just prior to page display -- after consideration, I'm not sure at all what this adds. At any rate, whatever the reasoning I had for submitting it originally no longer obtains. If someone else thinks it's a good idea, I guess it could be resubmitted.

2) Hook into Articles - It looks like the better solution is for any addon dev who wants to make changes to the articles module is to clone the articles module and just make the changes. The call to status_editor() adds data to App::$page['htmlhead'], and could mess up settings if the jot editor is going to be used. To fix that would require a second hook to change the behavior of status_editor(). And by that point, any dev would be recreating significant portions of the current module anyway and may as well just go that route. It's not that big/scary or complicated. So either an addon on it's own endpoint - or even using the facility for Zotlabs/SiteModules/Articles.php (see Zotlabs/Web/Router.php) is probably the correct solution.

3) HTMLPurifier - It was a first stab to lessen restrictions in certain cases for articles, web pages, wiki entries, maybe cards while still allowing the use of nomadic identity and automatic cloning of those items. Digging more deeply, it's clear that the the way things are transmitted (see include/zot.php::process_delivery()) means that any modificatons to HTMLPurify configuration would need to be universal (all item types) and site-wide (actually ALSO be implemented on all sites where channel clones reside) in order to work. So now I see the overall concern with changing it as proposed - to work, it would not only have loosened restrictions for the desired item types on the local machine, it would have needed to be a univeral loosening of restrictions. In that way, I agree. Bad idea.

I have an different approach/alternative that I'd like to float - but I want to sleep on it and see if any gotcha's come to the fore in the morning.

Anyway - thanks @Mike Macgirvin and @Mario Vavti for your patience... you have a much better handle on the code base than I do. I trust you both enough to know that when you give resistance to an idea, there are reasons - even if they aren't readily apparent. I imagine sometimes for you there isn't more than an initial "gut feeling" that it's a bad idea - but it would take you quite a bit of digging back through to figure out exactly why - which isn't a reasonable expectation for others to impose on you. At any rate, I wanted to put these notes here - mostly for explanation, posterity, and as an apology if I came off a bit pushy.

Meant to share this to the forums:
!Hubzilla Development !Hubzilla Support Forum
IIRC you can add forum mentions also in edits...
Thanks.. Wasn't sure and it was getting super late.
 High Range, Australia,  
!Hubzilla Support Forum !Hubzilla Development

Just a heads up. The time is slipping away and I would like to bring Zot6 to Hubzilla before the end of the year, but I'm now questioning if that's a realistic timeframe. There's much work to do and the conflicts between Zot6 and the way Hubzilla currently works are staggering to say the least. But here are a few things that may happen "soonish" and which *may* affect you...

1. The PHP minimum version is going to brought up to 7.0. Version 5.6 will be end of life on December 31st so this shouldn't surprise anybody, but I'm suggesting that this requirement is imminent. Please upgrade _now_  if you're running 5.6.  Things will start to break if you don't. The longer you wait the more things will break.

2. Redmatrix backward compatibility will be terminated. I think everybody who wanted to migrate has done so, but in any event I'm pulling the plug on the compatibility code.

3. The way reshares work is going to be radically different. I'm hoping current reshared posts will still render, but if somebody comments or likes these in the future, those conversations may not federate. In ActivityStreams (on which Zot6 is based) and many other federated networks and projects, you can't actually add commentary on reshared content before posting. This is unfortunate because it puts everybody in the network at risk of copyright infringement and without a "fair-use" defense. I highly recommend everybody get in the habit of adding a comment to anything you reshare, even if it involves an extra step. The ass you save could be your own.
Regarding #3, will we lose the ability to preface a reshare with commentary? It is a feature I appreciate.
I am planning to branch out 3.8RC by end of september, after (hopefully) the feature to app transition will be finished. Not sure if i can still squash in the settings changes but i hope so...

I am all up for it after that.

European Parliament Votes in Favor of Controversial Copyright Laws - Slashdot


The EU has voted on copyright reform, with members of European Parliament this time voting in favor of the extremely controversial Articles 11 and 13. The 438 to 226 vote, described as "the worst possible outcome" by some quarters, could have significant repercussions on the way we use the internet....
Apparently if you read the text of the bill, things aren't nearly as bad as we've been led to believe. Open source is exempted.
OpenSource content itself is excluded. Yes, see

Recommendation 2003/361/EC and
service providers that act in a non
commercial purpose capacity such as online encyclopaedia, and providers of online services where the content is uploaded with the authorisation of all right holders concerned, such as educational or scientific repositories. Providers of cloud services for individual use which do not provide direct access to the public, open source software developing platforms, and online market places whose main activity is online retail of physical goods, should not be considered online content sharing service providers within the meaning of this Directive.

But there are changed of the sort that there are fears that is is forbidden to upload something like a selfie in a football stadium. It would effect Hubzilla as well.
That sounds more to me as if Github/Gitlab etc. are exempted from installing an upload filter, but not "open-source" in general.

!Hubzilla Development

Since mastodon released their relay servers, I was wondering if that could improve the federation between those. As it is now for example one cant see posts from hubzilla channel on mastodon unless its sharing with that account already etc. I was wondering if we would post / get posts from relay would that change? Meaning that posts from hubzilla would be seen on mastodon side without prior sharing with the channel and the same way public posts on mastodon would be seen on hubzilla too.
  last edited: Wed, 12 Sep 2018 21:16:43 -0400  
It's sort of the same concept as the Diaspora relay servers, except for the ActivityPub protocol. FYI Pleroma has a competing implementation (which isn't compatible). Since ActivityPub is an addon, a relay driver would probably either need to be an option to that addon or self-contained (like we do for OStatus and PubSubHubbub (now Websub) and which is also a relay server).

Anyway, yes it has certain advantages much as you have described. I have no interest in firehose implementations personally because the basic concept tends to work against the decentralisation movement - leading to larger servers and concentrations of content and growing clusters of people around them. As optional services, sure. Do whatever you want.

Such mechanisms will surely find adherents. I'm not personally interested as it goes against everything I stand for and have worked toward, so I'm going to bow out. If you want it, #makeithappen.

I've  been working on what I call a 'hyperdrive engine' for decentralised networks which takes a completely different approach to the problem. Instead of working from the top down and distributing all content to all servers, it works from the bottom up and can bring in orders of magnitude more content to your server - but only content which is relevant in particular ways to you or your site members personally. This is working today and will come to Hubzilla with Zot6 but requires a different implementation for every protocol and a couple of protocols make this incredibly difficult. FYI, it does work with ActivityPub.
Started to move some of hubzillas core features to apps. Now thinking about how to best untangle the settings so that we can have a per app settings page instead of one overwhelming central settings page.

Help and inspiration most welcome :smiley_cat:

!!Hubzilla Development
I think separate products are a great way forward in that regard! And that may be in large part the answer. HZ is the "producer" platform Zap and Osada are the consumer platforms. It simplifies quite a number of things ultimately from a product focus vantage point.
  last edited: Wed, 12 Sep 2018 04:42:52 -0400  
Sleeping over it, it will be probably be much more straight forward to leave the settings where they are but allow them to be displayed per module.

E.G. /settings/network, settings/articles, settings/diaspora etc.

This will affect only "features" which are bound to a specific module and do not make sense somewhere else.

@M. Dent what you propose is what we basically tried to achieve with the skill levels - allthough slightly different. It turned out to not work so well since everybody has slightly different needs.

I think installable apps are the way to go. It appears this also works well for owncloud/nextcloud and is more like an operating system approach which boils down to what hubzilla actually is.
Ah, I think I'm seeing where you're going with the overall structure... That makes a lot of sense in many ways. WordPress has the same basic structure as well.

Kind of interesting... Taking everything as a whole and considering the entire "Zot" ecosystem, it looks like we're all reaching some of the same basic conclusions though we are approaching things from slightly different directions.

Also, while many seem to be concerned with first to market issues, I like that the focus here seems to be overall on a workable, sustainable, solid solution.


Worries Arise About Security of New WebAuthn Protocol - Slashdot


An anonymous reader writes: "A team of security researchers has raised the alarm about some cryptography-related issues with the newly released WebAuthn passwordless authentication protocol," reports ZDNet. "The new WebAuthn protocol will allow users of a device -- such as a computer or a smartphone -- to authenticate on a website using a USB security key, a biometric solution, or his computer or smartphone's password." But researchers say that because WebAuthn uses weak algorithms for the operations of registering a new device, they can pull off some attacks against it.

!Hubzilla Development
I love this quote:

PKCS1v1.5 is bad. The exploits are almost old enough to legally drink alcohol in the United States
@M. Dent a contact of mine had the new reputation addon enabled which resulted in me loosing permission to comment/like posts of that contact in my permissions list.
Anyway, wanted to let you know that i could still comment and like the contacts posts allthough i visually had no permission.
In case you tested this and it worked for you as expected there is the additional info of that contact having a clone where possibly the addon was not installed (have not checked this though).

!Hubzilla Development
It turns out that the plugin was also enabled at the clone.
Ok. The cause was likely either the messed up recovery calculation or the 'enabled' checks that are both fixed in the most recent commit.
@Mario Vavti - If you retest - let me know if there's anything else that crops up.