Account - Invite - Register ("air")
@!
Hubzilla Support Forum @!
Zotlabs|Hubzilla Development 1st
@
Mario Vavti and to all the other developers: congratulations on version 5 of Hubzilla. That was and is pretty hard work. I'm very happy to see how it's improving.
2nd
After around 9 months of absence from Hubzilla, I would like to transition my rewritten Invite and Register functionalities to version 5.x. As it concerns the modules, libraries and templates to Account, Invite and Register, a Git Branch on Framagit sn/core is named as "air.5" (
#^https://framagit.org/sn/core/-/tree/air.5 ).
Since April 2020, there is a working version 4.6.2 in sn/core as a fork based on version 4.6 in the master of the stable prod branch of hubzilla/core. Since then the 4.6.2 version runs stable on some of my sites. Since January 2021, Hubzilla version 5.2.1 is available in the hubzilla/core repository and recently updated as version 5.2.2. AIR is currently targeted on base 5.2.2 prod.
Because the upgrade to AIR has a massive impact on the overall logic of registration and account management, I had not yet found a suitable time to prepare the code maintenance to a conflict-free merge request for hubzilla, especially since both the Prod and Dev branches were maintained in parallel at the time. The merge between Prod and Dev looks more dynamic since version 5. A possible transition on the fork is currently running in such a way that sn/core master is always currently synchronized with hubzilla/core master on short notice, in order to clean up merge conflicts between Hubzilla master and AIR as close in time as possible. My hope is that this will allow a relatively quick transition first to an AIR branch on hubzilla and then to the prod (master) branch there. Currently hubzilla/core 5.3RC is in the pipeline and will probably go in from Dev to Prod soon.
I had announced the functionality and logic of AIR in several posts in the Hubzilla support forum in the past (see ref below). There are three features associated with AIR: The previous logic can continue to be used as is, extensions can be used if desired, and there have been a number of significant logic and code fixes that are more than just "nice to have".
The Invite App, which was already part of the core, has received urgently needed corrections in the coding (inconsistent flow logic has been cleaned up) and the invitation texts can now be controlled via templates. The templates are internationalized, which eliminates the static invitation text in the code. According to the templates, different invitation formulations can be selected (e.g. for friends, or formally polite) and can be extended by further templates for different languages. Invitations can be sent by users and administrators - with different quotas. Due to the Invite App alone, a schema change of the register table made sense, which could be used at the opportunity for an extended registration functionality.
In addition to the previous variants of registration (with or without invitation, with email address, with or without admin confirmation), AIR offers another option, which may sound adventurous at first because of its title (as "anonymous registration"), but which can be a security gain and simplification for the administration of the instance if it is designed carefully. Anonymous registration is not a new idea. Some will be familiar with the messanger Threma, which is one of the few very secure and privacy-friendly of its kind, and it doesn't even require a cell phone number.
Email registrations certainly have advantages (for example, in a corporate network), but they also have significant shortcomings if used in an unsophisticated manner. A first limitation is that not every email recipient will be reachable from a Hubzilla instance. Some large mail and phone operators block many email domains (or IP address ranges) for various reasons. In fact, worldwide spam is disproportionately higher than legitimate messaging.
The anonymous registration in AIR does not require an eMail address. In fact, only a password is required. And yet the user has to confirm the registration and this works safely and well, even if (configurable) administrative consent is not even required. The processes of the registration are adjustable time controlled. In combination with Fail2ban there are besides quotas sufficiently good control possibilities, in order to be able to repel masses of expected Spam registrations easily (because automated). When I wanted to use the combination with F2B at the beginning of February, I quickly locked out myself, because after months I had forgotten that this had been switched on long ago.
Just to clarify, AIR is not a new product, just the (temporary) name of a branch in Git. Would be happy if the branch would enter Hubzilla. A good time for this could be soon 5.3 Prod Final.
Ref:
2019.12.13
#^Invite App2020.01.05
#^Email invitations2020.01.10
#^qms (qualified message source)2020.01.14
#^email invite / register2020.02.27
#^Register, Account, Invite ...2020.04.23
#^Invite, Register
