Did some digging, and it looks like it would be more involved - it would require adding support code in the query engine (like Spaces), and making another DB call (Flags are their own objects), or re-implement Flags using Edges.

This is totally scarying but I'm quite interested in exploring the proposed solution :)

We don't allow cross-application table joins

Any insight into why this is the case? Also do you know if there’s any documentation to what at edge is, other examples of edge things?

We don't allow cross-application table joins

The logic is that each application's database might live in a different physical db cluster (for the really big installs), so it would be technically impossible to make such a join.

any documentation to what at edge is, other examples of edge things?

Existing things that are Edges are Subscriptions, Task Dependency relations, Task-Revision relations (There's a full list in https://we.phorge.it/config/module/edge/).
The docs are kinda short: https://we.phorge.it/book/contrib/article/using_edges/

The bird's-eye view for edges is that they are stored twice - once in each side of the edge, so they are always "local" to any application's DB. They have source phid, target phid, and metadata.
Each edge also has a "reverse edge" for the other direction (so "Revision in Task" edge has Task as a source and is stored in Differntial's DB, and it has a corresponding "Task has Revision" edge with Task as the source which is stored in Maniphest's DB).

Interestingly: https://secure.phabricator.com/T10574 argues for removal of the additional data from edges.

I looked into this again.

• Flags don't have PHIDs, and don't use Transactions.
  • They are also one of the few "objects" that can be out-right deleted from the web UI.
  • This kinda makes sense in the context of being "very private". I'm inclined to keep this oddity.
• Since they don't have PHIDs, basically nothing else can operate on them.
• There's a single table, and a flag object is identified by "userPHID, type, targetPHID" set, with type being a the phid_get_type() on the targetPHID.

Instead of completely re-implementing, I'm thinking to add the Edges with only the Color (which I imagine is useful in the both use-cases described) in the edge-data, and have the rest of the data left where it is now.
The only unknown right now is "how to create an edge without the relevant transactions", and how to make the extra search operator.

btw, for the "search" use-case I'm describing, I'm imagining something like a Function on Users/project, so I can search, for example "Tasks that are assigned to users which I flagged with a green flag" or "Tasks that have a tag that I flagged with a blue flag".
And also, "Revisions that I flagged with any flag".

This was both harder and easier then I expected. I got to crash the IDE and hard-code a bunch of stuff, but this actually works. Didn't even start on the Edges implementation yet - I'm directly using the Flags table.

Searching for Tasks like that takes at 2 round trips to the DB - one to get the project PHIDs that are tagged, and one for Tasks. Adding edges won't actually make this better?