So here's how I'm thinking to do this.

Generally

• Hidden projects or Drip Lists don't appear on "all projects / lists" screens.
• They also don't appear on public profiles.
• They appear on your personal dashboard, but only if the "show hidden" toggle is enabled, as per the designs.
• When trying to split to a hidden Drip List or Project, the list editor should display an error like "The List / Project is hidden and cannot be split to".
• If someone or something is already splitting / streaming to a now-hidden list or project, that stream and split DOES get displayed on the respective project / drip list / profile pages, BUT the split recipient / stream should be slightly greyed out with a warning icon.
• When directly accessing a hidden list or project via URL, it should render the page, but with a large warning at the top that says that it has been hidden and in case of a list, possibly transferred to the recipient (with learn more link to docs).
  • We shouldn't make them outright 404s, because these hidden entities may still be receiving and splitting funds. It's important that the platform remains fully transparent and flow of funds can't be entirely hidden in this way.
• Pages for hidden entities have meta that prevents them from being indexed by search engines.

Project visibility

This one is simple. When you're in control of a project, you can set a visible boolean in metadata to false. Event processor should index this, and API should return a visible boolean in project data. If false, app treats it as hidden as described above. Projects without visible boolean (old metadata version) are presumed visible.

Drip Lists

A bit more complicated, because we also want lists to be hidden by default when transferred to you. I'm thinking:

• When minting a new list, it sets a visible boolean to true in metadata.
• When the list metadata is being indexed, event-processor stores visible: true for the list. This is also exposed by the API.
• If a transfer event is indexed subsequently (aka the list is transferred), event processor updates the list visibility to false.
• If a subsequent metadata update event for the list is indexed that sets visible to true once more, event processor once again updates the list as visible in metadata.
• If at any point a metadata update is indexed where visible is set to false, event processor always updates the list as invisible in the DB.
• Backfilling the visibility of existing Drip Lists when we launch this feature will be a bit tricky. We can't just apply the current logic to all previous transfers, because that'd leave some transferred lists like the Radworks one suddenly invisible. We also can't presume lists as "visible" if their metadata is outdated (missing visible key), because anyone can publish metadata in the future that doesn't include this key, and abuse that to transfer a Drip List to someone and have it be visible by default. So:
  • We should pick a particular block number shortly after the feature is launched, from which point onwards the new visibility logic applies.
  • Before that block number, all Drip Lists are always presumed visible, even if transferred.
  • After that block number, the logic above applies, and lists become invisible when transferred.
  • The event processor including all this new logic needs to be deployed and active before the chosen block number, and the app with support for managing visibility needs to be deployed shortly after that block, so that no attempts to hide a list or project are ignored.

That way, Drip Lists are visible after minting, can be hidden at will, and also are hidden by default after being transferred to someone else.

When trying to split to a hidden Drip List or Project, the list editor should display an error like "The List / Project is hidden and cannot be split to".

would be cool if you could still split to a hidden list. for privacy's sake, some people might want to do this

When trying to split to a hidden Drip List or Project, the list editor should display an error like "The List / Project is hidden and cannot be split to".

would be cool if you could still split to a hidden list. for privacy's sake, some people might want to do this

Idk. It wouldn't be private at all — the info would still be visible on-chain and even our API, just marked as hidden, so it'd be an illusion of privacy at best.

When trying to split to a hidden Drip List or Project, the list editor should display an error like "The List / Project is hidden and cannot be split to".

would be cool if you could still split to a hidden list. for privacy's sake, some people might want to do this

Idk. It wouldn't be private at all — the info would still be visible on-chain and even our API, just marked as hidden, so it'd be an illusion of privacy at best.

we have to make that clear regardless

in case of a list, possibly transferred to the recipient

what do you mean? how could being hidden also be the same state as transferred?

in case of a list, possibly transferred to the recipient

what do you mean? how could being hidden also be the same state as transferred?

If we go with what I propose above, lists would be hidden automatically when transferred and would remain that way until explicitly set to visible by the new owner.

@brandonhaslegs when you have capacity, could you update the designs with the above in mind?

need to know what splits & streams to hidden things look like, what viewing a hidden drip list or project looks like, and also probably update the visibility toggle to explain things clearer (no expectation of privacy etc.)

I'd also write up a docs page for this so we can link to it.

All else sounds great to me!

Drip List

Project

Can comment or look at the full design here

Worth noting that the support card would be gone when in the hidden state.

Update design and wording to