In T15948#21503, @Cigaryno wrote:

There must be a function that allows Conduit methods to be used by logged-out users. It's just that there are hardly any methods using that function.

There must be a function that allows Conduit methods to be used by logged-out users. It's just that there are hardly any methods using that function.

@avivey does this look good to you?

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 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.

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?

I think it's relevant to have a status site (likely at status.phorge.it). Uptimerobot sounds like a good option and is used by translatewiki.net.
One thing that's optional to have (likely not possible with Uptimerobot) is a Daemon status checker, as @avivey pointed out when they forgot to start the daemons at some point. For this, a custom status checker that calls a daemon that's not for making edits or changes can be used.

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

I don't know if what I done on D25935 is correct, but as usual, Request Changes if I did it wrong.
I relied on the code on PhabricatorUserEmpowerTransaction to try to make PhabricatorApplicationUninstallTransaction require MFA if enabled.

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 will submit a patch shortly.

In D25926#25064, @aklapper wrote:

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

Can this be further reviewed?

Looks like a Good Starter Task.

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).

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.

In D25926#24890, @avivey wrote:

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

@valerio.bozzolan could you please add to either H28 or H29 Affected files contains none of map.php?

This is one great Wikimedia patch being upstreamed. Should I make this a sub-task of T15081?

Took the opportunity to fix a typo in the summary.

On Outbound Email rules, does the Do Nothing action neither send an email nor a notification?

In T15203#21226, @valerio.bozzolan wrote:

(M is short for Mockup probably)

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 T15203#21219, @avivey wrote:

The V123 syntax is disabled by remarkup.ignored-object-names config by default; The default is /^(Q|V|M|P)\d$/ (basically anything starting with Q, V, M, or P), for "Q1" (biz-talk for April), "V1" (for versions), "M1" (for ?????) and "P1" (Jira for "important bug").

I'm honestly surprised about layout=inline working for {T123} - I thought is only works for images. But it can probably be made to work for Votes (or rather, all objects) like it does for tasks.

What you see is 100% normal regardless of your pixel density, display size and resolution.
With a similar approach to T15920, this can be achieved. However, I think there is one disadvantage: text may be crammed with a side hierarchy, resulting in lots of newlines for documents with long titles.
You can create a task now that you are member of Trusted Contributors.

In D25889#24581, @aklapper wrote:

Hmm, maybe should not change ->setURI("/people/tasks/{$id}/") because there might be external third-party code relying on this?

@vabocharov please set the view policy of F3250825 to Public.

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.

In D25905#24572, @aklapper wrote:

@Cigaryno: Oops, I am sorry! I had forgotten that this proposal also existed as it wasn't linked under "Revisions and Commits" in T16007. My fault. :-/

Obsoleted by D25909: Diviner: Contributing Code: Update section on Prototype Changes. I think @aklapper should have instead commandeered this rev but it's still okay to have a new revision instead.

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.

@valerio.bozzolan try to create the global rule now.

Fix the URL.

Sounds good. It should have no CAPTCHA configured (maybe we.phorge.it needs CAPTCHA to reduce unused account creations) and just like on secure.phabricator.com (see this), there should be a notice for users willing to demo the software on the demo instance and not the upstream instance (in Phabricator you can create a Phacility test instance and even to this day, this is still possible).

@speck if you think this thing works properly, you can either resign or click on Accept Revision, because when @valerio.bozzolan accepted the revision, it still appeared as Needs Revision.

This is a great proposal. Did anyone think of showing two separate queries on Tasks: Assigned and Authored. In my opinion, it just makes it harder to scroll down to authored tasks which is why it makes more sense to have separate Assigned Tasks and Authored Tasks views on the profile menu.

@Tgr you want something like this?: T16008: Provide an easy way to link to a Phorge task in a user-friendly way
If so, just enclose the task ID in {} (ie {T16008}

I've created T16007: Discuss the policy for contributing to prototype applications.

Fix the typo in line 167