Private groups don't work at all? If that's the case it seriously needs to be fixed because nobody I know will even consider moving to Friendica if they can't create a private group.

I'm working with the existing form. It requires entering the parent account's password. I can't change that restriction.

Users (not just the new ones) would expect that it is possible to create groups in their chosen platform.

I don't understand what you mean by "in their chosen platform"? The platform is Friendica, there's no other choice, this is a Friendica account form. This is not the general sign-up form, it only appears when you're already signed in and want to add an additional account under your main one.

I agree with that. I was considering:

• Personal (standard account)
• Personal Soapbox (auto-approve Follow requests)
• Personal Love-all (auto-approve Friend requests)
• Organization Page
• News Page
• Public Group
• Restricted Group
• Private Group (experimental)

Not sure about including the explanations behind Soapbox and Love-all though.

I don't think "connection request" or "connections" is the way to go with terminology. I think most people are familiar with the terminology of "Friend request" and "Followers" over "connections."

IMO Friendica should really try to use the more common terminology. Which is why I think "nickname" should also be replaced with "handle." "Circles" is probably fine, though "Lists" seem to be the more common term for such a feature. That's what Mastodon calls it. That's what Facebook used to call it, when they had that feature.

Is there any reason I shouldn't be exposing the account type and page flag data on the front-end?

The way I wrote my mod each option has a numerical value. The first digit represents the account type and the second the page flag. So any URL with parameters to auto-select an account type from the dropdown would be like ?type=32.

But it could also be written to use strings for the option values and then equate those to numbers on the backend, so then the URL with params would be like ?type=group.

I'm not doing anything with the initial register form for the primary account when you first sign up.

This is the additional account registration form that you'd normally navigate to by one of these flows:

Main Menu > Accounts > Register a new account or Main Menu > Settings > Manage Accounts > Register an additional account or the "+" on the Groups widget.

After registration it takes you to the account switcher /delegation page.

Currently if you want that new account to be for a Group or Page then you have to use that account switcher to log into that new account and go to Settings > Account > Advanced Account Types.

For the widget link, instead of just going to /register/[i] it would go to [i]/register/?type=group which would auto-select "Public Group" from the drop-down.

I guess I can see how a new endpoint for the "Create Group" only showing the three Group options in the drop-down makes sense. Then it would also be nice to create an endpoint for a "Create Page" link that only showed "Organization" and "News" in the drop-down.

But I could also do that on the front-end with the JS to remove all the non-relevant options from the DOM based on the URL params.

My goal was to eliminate the need to log into the new account in order to change the account type and instead just create the account with the desired type. So as soon as you do log into it that account is ready to go for the intended purpose.

I've been playing around with a "Private Group" on my development server and it seems to function the way I expect it to, which is like my standard Personal account. Other users can request to follow the private group but I have to manually approve them. And until I do they can't see any posts I made to "followers" only. I have no idea how this works with accounts from other platforms like Mastodon. Maybe it doesn't work and that's the problem?

I wouldn't want notifications for that account to "bubble up" to my parent account. I think it makes sense to stay within the context of that add-on account. At most maybe there should just be a notification that your add-on account HAS notifications so you know to switch accounts and deal with them?

I'm not sure how that would be implemented though since the accounts "live separately" from one another. In the database the only difference really is in one column if the entry is "NULL" it is a parent account but if there is an ID number it's an add-on account. If you go into the DB and manually change the ID number to NULL it becomes a stand-alone account (albeit with the same password and email address as the parent account that originally created it).

Thinking about how this works on Facebook, for PAGES you actually do have to switch to an additional account to manage anything to do with your page.

For GROUPS though they're under your parent account, which is different from how Friendica does it. Though I'm an admin on a friend's Facebook Group and post/manage it from my primary account, which I guess would be the same as if they'd had a Friendica Group and made me a delegate for it?

And Followers and Friends can post TO Friendica groups so I don't see how that's all that different from posting to a Facebook group. Or am I missing something?

I agree it's a little confusing that Friendica's Groups and Pages look exactly like any other account. Some of that could be addressed through UI changes in a template or theme, but presently there isn't really any CSS handle to identify when you're on a Group or Page profile. It's just "mod-profile" or "mod-contact" not "mod-group" or "mod-page" which would allow targeting them for different layouts. *sigh* Yet another thing I need to look into implementing in the theme I've been working on.

I think "Circles" is probably better than "Lists" (or "User Lists" or "Custom Lists" or whatever). Diaspora has Circles, right? Google Plus (for anyone who remembers that) had them. A social circle is a clear enough concept.

I'd be against dropping the "Friends" terminology, especially because the platform is "Friendica" and anyone from Facebook gets the meaning and difference between "Friending" someone and just "Following" them. I never liked the way Twitter did it. I never liked how Twitter did anything. I actually don't like Mastodon or Bluesky very much because they are too Twitter-like.

I can see the value in the URL parameters being human readable rather than a "magic number." Really the only thing I don't like about switching from a number to a string is processing the number into the database takes 2 lines of code while the string requires 36 lines of code (because it needs constants defined first then needs a switch-case to equate it to the numbers).

But that part is all on the backend and invisible to users. The URL params are visible to users in the browser address bar, so should probably be human readable.

Out of curiosity, is there some particular reason to hide the label on password fields? Both the core and theme field_password.tpl templates have this in them:

{{if $label != false}}
	<label for="id_{{$field.0}}">{{$field.1}}{{if $field.4}} <span class="required" title="{{$field.4}}">*</span>{{/if}}</label>
{{/if}}

It's easy to override it by putting {{assign name="label" value="true"}} before the template call, I just don't understand why it normally hides the password field label? Especially since it actually breaks the layout of the "Register" form in Vier.

Okay, I've incorporated the suggestions and I've got it working on my Dev Server.

So the final product will use human-readable URL parameters, so if it is "?type=group" only the three Group options will be in the dropdown list. And I did something similar for the "Page" and "Personal" options. No/invalid params means it shows the whole list of account type options. Trimming the list and pre-selecting is now handled on the backend in PHP rather than on the front-end with JS.

I'll try to put this together into a PR sometime this weekend.