!
Hubzilla Support Forum Not easy for me how to start some posts about what I did in the last weeks. So let present a simple screenshoot, that will show a pice of what you are familiar with, but there is very much more hidden behind.
Time ago I started work with the Invite app. Soon the requirement growed to dive deeper into the system. As deep enough as to see, what else could be done to have a consistence environment about the claim of Hz/Zot between "anybody has the right of a digital identity" and the lot of configurations and permissions to protect the system against such of the "anybodies" entering the runnig systems with the not very best intentions.
Beside this spirit, the question about what really could be an alternate to FB and the like, I only can imagine Hz/Zot as the technical solution perhaps may have a chance, when, - yes - when many conditions are solved. One of those questions is, what happens when you run a system where 1000 users want to register, not in the systems lifetime but each day. Poor instance-admin, who has to spent much time to click "agree" or "deny" with his thoughts, should I say yes, should I better say no etc. And, does really want heshe receive 1000 emails with the messages of new register requests? The amount of 1000 is artifical, imagine 200, imagine 2000, whatever. Just a little hugh bit more then as all the running fedi servers assume and handle today.
Do not assume I have the one best answer. But I have coded some solutions in the last time. Let show one screenshot more
Up to now, there are several closely related configuration options for account registration (
REGISTER_OPEN,
REGISTER_APPROVE). In combination with
config/system/verify_email the access can be very easy or a bit more complex. The
config/system/invitations_only option provides an even more stringent access requirement.
Imagine an access scale ranging from 0 to 10, where 0 is the completely free and 10 is the ultimate difficult new entry. The previous setting options could be seen somewhere in the range 2 to 5.
The easiest way through the registration process is by entering an email address and the password to be assigned to the account. This does not correspond to a completely free access, because although the given email address does not have to be confirmed, it will at least be checked if the email domain is a valid one and is not registered in the blacklist of the own instance (imaginary scale value 2).
The previously more difficult registration variant is bound to the verification of the email address by confirmation combined with the administrative approval (imaginary scale value 5).
However, all scenarios are combined with the email address. What is the value of an email address in terms of authentication? About every 2 years IBM published a report about the worldwide email traffic, the last one in 2018. 500.000.000.000 (5G) emails are sent every day. 95% of these are classified as spam (2016 ~ 93%). Those who are familiar with email protocols will know how easily email addresses can be spoofed in many ways. Do you trust the address of an email sender? Probably yes and no, as I do, because other characteristics of the message increase or decrease the level of trust. Funnily enough, FB and colleagues are apparently also in love with email verification.
A largely completely anonymous registration cannot be bound to an email address. Uncontrolled access (scale 0) can't really be intended for a platform as powerful as Hubzilla/Zap. It is also desirable to keep the many digital trolls, bots, spammers, stalkers etc. out.
When I think about Hubzilla/Zap related digital identities, an email address is a secondary identity that should lead to the target of a primary ID and that is known to be formed from
channel@instance.tldIn this context I find the term
"dId2" useful and will use it more often now. New configuration options support a
dId2 that is artificially created; simply creating something like "d123456". Configured accordingly, the registration form allows to waive the requirement to enter an email address (the field can be left empty), asks for the password to be set and the agreement to the tos. Easily done and only slightly less reliable than an email address. I would like to classify this as a scale value 1. Configured accordingly means and looks like this:
REGISTER_OPEN or
REGISTER_APPROVE,
email_verification off. But internally email_verification off is disregarded and self verification is forced. That should make sense? And the instance admin should confirm something like d123456? You do not have to, instead of
REGISTER_APPROVE you can set
REGISTER_OPEN.
But don't panic. There are measures that help against digital plagues. These include very analog things: time and frequency. Immediate anonymous access that can be used in just a single transaction (with a few entries transmitted as a single unit) is a destination that is always popular. However, if the destination has to be called up a second time, combined with a certain waiting time, it becomes more difficult and therefore less attractive. And if the destination on the second visit also wants to know some secret information that was mentioned on the first visit, then this is already connected with effort. For a person such a thing is not a big problem, it only requires a little patience and a notepad. A digital bot, on the other hand, is more complex to construct: it requires memory and time controls that are not even quickly given.
The configuration option
config system register_perday is already available and regulates the maximum number of registrations per day. This option is always useful and the assigned value also depends on what additional measures are taken. For example
config system register_sameip which limits the number of registrations that can be served from the same IP address. If three registration requests are allowed, a single attacker does not have the prospect of mass prey. And if the configuration options are cleverly set, the bot will block itself for a long time.
Let's look at the registration in Hubzilla/Zap like a thoroughly bureaucratic institution, as an authority that has more recreational breaks than working hours. A new configuration option
config system register_duty regulates when registration applications are accepted within the week. Different and multiple times can be set for each day. For example, on Mondays from 9:28h to 10:46h and 14:08h to 15:25. Tuesdays have different times, and as with any real proper bureaucratic establishment, is closed on weekends.
To be continued ...
