@agd Working on this now. I started off making it so that when a user is unauthenticated, all blogs and posts return a 404 (to not reveal the existence of any blog). But I'm wondering if it'd be better to send a user to the login page, instead, for better convenience. If so, we could still obscure existence of individual blogs by simply sending all routes to the login page when unauthenticated. This could be the same for the API -- all routes would just require authentication.

What do you think?

So this is likely a comment that is more meta than the ticket itself, but I think that I'd like the "story" to be something like:

Overall Goals

• should not "leak" presence of things via URL/API like username, or other identifiable things like "title"
• should always redirect users to either an instance "splash" page or the login page.

In fact, with gitea, we're actually specifying the default page to be "explore", which when you do that in cohort with having a registration disabled instance always defaults to prompting login for non authenticated users (because you're default route requires login). If I didn't specify this then you get some sort of overall gitea page, which is cute... but isn't customizable without me mucking hard in the template. It'd be nice to be able to choose between forced login, or a splash page that explains the reasoning for the instance... like someone discovers it on line and wonders what it is, you could explain your instances reason for existence (this is more for the case where you want people to request registration).

For Unauthenticated Users

• entry point is someone linking a URL
• check session/login, if not, rewrite them to a login prompt
• post auth rewrite back to url they were seeking

For Administrators

• simple "toggle" for federated or non-federated "mode" where you can decide that your entire instance of "write.as" tooling is non-federated (this would be nice on all tooling, e.g. snap.as)
• registrations + can be disabled entirely for the instance, use a CLI or GUI based user creation system (default closed instance) + can be set to "approval" where someone can request an account and a set of admins an approve those accounts (this is more complex and not required for my goals, but seems like a "closed" community would be interested in this type of workflow)

Thanks, this all makes sense.

I'm going to send users to the login page when unauth'd for now, and then we can see how that works in combination with T574 to determine whether or not more landing page customizability is needed.

As for the administrator items:

• We currently have a federation config flag that takes care of this (and agreed, it should be on all tooling).
• Registrations currently can be disabled with the open_registration config flag, and users can always be created by running writefreely --create-user username:password or generating an invite link (config docs and command docs).

I do like the idea of an approval workflow! I'll keep this in the back of my mind to see how it might work into larger plans.

Just opened a pull request (GH#123) for this. I still need to verify that data isn't leaking on some ActivityPub endpoints (namely nodeinfo and webfinger), but the core of everything is there and ready to try out.

Addressed those issues in most recent commits.