Looks good to me, thanks!

Looks good, yeah.

In D25935#25149, @Cigaryno wrote:

Why would a cancel URI be needed?

@avivey does this look good to you?

In D25926#25147, @Cigaryno wrote:

But so far this is nothing meant to be hidden from users who can't edit the repo.

In D25935#25135, @aklapper wrote:

After these steps I get Unhandled Exception ("Exception"): This transaction group requires MFA to apply, but the Editor was not configured with a Cancel URI. This workflow can not perform an MFA check.

Why would a cancel URI be needed? Do you know a Cancel URI for an app with something that prompts for MFA (ie. exposing Passphrases, empowering users, signing comments with MFA, managing your VCS password and SSH keys)

In D25935#25144, @Cigaryno wrote:

In D25935#25135, @aklapper wrote:

Which "an application" exactly?

Any application were canUninstall is not set to false (thus not a required application).

That's what I tested (as the Files application can be uninstalled). Which exact application(s) did you test?
I'm surprised that you did not run into the same problem as I did described in my last comment...maybe it's related to not being an admin?

In D25926#25145, @aklapper wrote:

Socially I remain unconvinced about use cases. Implications are for example exposing hidden (or internal?) URIs under URIs or "Working Copy Status" stuff under Basics to the public. I just so far do not think it's a good idea.

Tested this locally; technically it looks correct to me.

In D25935#25135, @aklapper wrote:

Which "an application" exactly?

Any application were canUninstall is not set to false (thus not a required application).

As which type of user?

A user with the Can Configure Application capability (by default admins).

Fix typos reported by @aklapper.

In D25936#25132, @aklapper wrote:

@Cigaryno: Thanks! Could you elaborate why the change in .arcconfig is needed?

Clear Test Plans with URIs are welcome - the less others need to think "how/where to do that" the easier gets testing.

@Cigaryno: Thanks! Could you elaborate why the change in .arcconfig is needed?

Should be fine after these two changes :)

I don't know why, but O1 has to be manually added as a reviewer as it does not own R10.

Thank you both for the conversation here and further thanks @Cigaryno for the patch! :)

Make lint happy

Mention closed-source apps in addition to open-source apps per @aklapper

Per @aklapper, it's best to show both closed-source and open-source TOTP apps.

In T16018#21478, @Cigaryno wrote:

In T16018#21476, @aklapper wrote:

I'd personally not remove common proprietary software options (as it makes life of users potentially harder if they already have such an app installed) but list FOSS options first.

Some FoSS devs may not be familiar at all with open-source TOTP apps. I personally use Google Authenticator so I agree with you and also, I have my TOTP content on WinAuth too, which is unmaintained however I am not ready to switch TOTP app on my Windows PC (my revs from now on are created from an Ubuntu VM due to the arc troubles I am having on Windows).

In T16018#21476, @aklapper wrote:

I'd personally not remove common proprietary software options (as it makes life of users potentially harder if they already have such an app installed) but list FOSS options first.

In D25934#25089, @aklapper wrote:

I'd prefer not to remove common proprietary software options but list FOSS options first.

I'd personally not remove common proprietary software options (as it makes life of users potentially harder if they already have such an app installed) but list FOSS options first.

I'd prefer not to remove common proprietary software options but list FOSS options first.

I will submit a patch shortly.

In D25926#25064, @aklapper wrote:

What is there to "further review"? It's two lines...

What is there to "further review"? It's two lines...

Can this be further reviewed?

In D25926#24899, @Cigaryno wrote:

robots.txt can have the solution for that (see below).
[...]
For search engines, the solution is to add this to robots.txt:

In theory yes if everyone behaved. In practice, robots.txt is ignored and LLM/AI crawlers are ruthless. (For example, GNOME GitLab admins recently installed Anubis to run background checks on your machine.)

In D25926#24898, @valerio.bozzolan wrote:

• more search engine rabbit holes (but maybe not that bad)

robots.txt can have the solution for that (see below).

Uhm. Good points:

In D25926#24895, @aklapper wrote:

Why would a logged-out user (who does not want to or cannot create an account) want to know about Repository management log or Repository limits? I don't see how that's their business (or interest)?

In T15999#21434, @aklapper wrote:

Some items in the task description make me a bit uncomfortable in my instance.

I don't think you need to be uncomfortable on your instance (phabricator.wikimedia.org)
For Herald, it looks to be restricted to trusted contributors to restrict who can create personal rules (they actually can vandalize tasks via personal rules with the action set to claim the task), that's not something to take care of at all on your instance.
Project members, maniphest reports, user tasks and badges are actually useful for logged-out users.
But everything that's Diffusion-related sounds pointless for your instance as every repo is a read-only mirror of the repos on a Gerrit instance.

Why would a logged-out user (who does not want to or cannot create an account) want to know about Repository management log or Repository limits? I don't see how that's their business (or interest)?

Some items in the task description make me a bit uncomfortable in my instance. Why does everyone need to see Diffusion sync, pull, and push logs? Why Herald transcripts? Why repo management if you cannot manage? What are actual use cases which outweigh security implications?

In D25926#24890, @avivey wrote:

There might be some security implications to this.
Why is this needed?

There might be some security implications to this.
Why is this needed?

I'm not familiar with MediaWiki's packages - the model I'm copying is VSCode.
My thought is that in the install manual we'll say "now run ./bin/extensions install phorge-recommended-extensions" (near the ./bin/storage) step, and phorge-recommended-extensions would be the equivalent of "extension pack" hosted on the default Extension Store, which is hosted here.
(VSCode also has "bundled extensions", which I think doesn't work for us because we use "clone the repo" as the primary distribution system).

In T16007#21223, @avivey wrote:

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

Ideally, any current Prototype can be either promoted to Core, extracted to its own extension, or removed completely. Each extension/author can have their own policy on contributing.

Already, any new app that would be considered "Prototype" today should just go in its own extension, and we decided to remove a couple.

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge. This should let us know if it should be promoted to core, separated into an extension, or removed completely if no one uses it (like Releeph and Phragments). Or even better, hold a Slowvote for each prototype application's future and possibly have Phorge's customers to vote (maybe notify as much as possible by creating a blog post about the vote to notify those who use the Atom feed).

I'm not sure that "usage" is really the best way to choose between "promote to core" and "extension"; The way I imagine it, in addition to the Core, we'll have a set of "highly recommended extensions" maintained, and a single step to install all of them when setting up a new machine. In that world, any app that can be separated out to an extension will be.
The prototypes can usually be curved out easily, without effecting the rest of the code.

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

Really!? Phacility SaaS instances do not allow enabling prototypes and self-hosted Support (from the Support application on admin.phacility.com that was oddly marked as Prototype) likely wasn't even available for prototype applications.

In T16007#21196, @Cigaryno wrote:

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge.

See T15501: Voluntary Usage Survey App basically.

Or even better, hold a Slowvote

Please no popularity contests (with even higher self-selection bias)...

In T16007#21194, @avivey wrote:

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.

Prototypes that need a long way before being promoted to Core are those that should be separated into extensions.

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.
The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

In T16007#21080, @aklapper wrote:

I do not think changes are necessarily needed, because it already says "With rare exceptions".

Bug fixes and security patches are indeed exceptions but not rare exceptions, assuming they fix problems with rough prototypes.

I do not think changes are necessarily needed, because it already says "With rare exceptions".
Regarding the proposal, I do not believe that "prototype applications [...] are often subject to significant changes" either.

I wonder if shouldAllowPublic() was just forgotten or if the idea behind was to exclude web crawlers (as querying those lists en-masse could be expensive).

Most of these can be done by adding the following to controller files related to query, list, and view files:

Knowing rHP will be replaced by R10, I will submit a patch to close this task.

This is forgotten, and honestly not something really required.

I've set can create to Trusted Contributors for now. I don't see a problem with people being able to create documents.

Currently limited to Trusted Contributors, which is enough as these users can be trusted not to break this install.