Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hide Projects and Drip Lists #1242

Open
brandonhaslegs opened this issue Oct 4, 2024 · 9 comments
Open

Hide Projects and Drip Lists #1242

brandonhaslegs opened this issue Oct 4, 2024 · 9 comments
Assignees

Comments

@brandonhaslegs
Copy link
Collaborator

brandonhaslegs commented Oct 4, 2024

image

Since we've made so many test projects on chain, we need a way to hide them too.

Also want to be able to hide the test stuff I've done on mainnet 🥺

image
@brandonhaslegs brandonhaslegs self-assigned this Oct 8, 2024
@efstajas efstajas self-assigned this Oct 15, 2024
@efstajas
Copy link
Contributor

efstajas commented Oct 18, 2024

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.

@brandonhaslegs
Copy link
Collaborator Author

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

@efstajas
Copy link
Contributor

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.

@brandonhaslegs
Copy link
Collaborator Author

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

@brandonhaslegs
Copy link
Collaborator Author

brandonhaslegs commented Oct 18, 2024

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?

@efstajas
Copy link
Contributor

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.

@efstajas
Copy link
Contributor

efstajas commented Oct 18, 2024

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

@brandonhaslegs
Copy link
Collaborator Author

All else sounds great to me!

@brandonhaslegs
Copy link
Collaborator Author

Drip List
Image

Project
Image

Can comment or look at the full design here

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

jtourkos added a commit to drips-network/events-processor that referenced this issue Oct 31, 2024
@efstajas efstajas mentioned this issue Nov 1, 2024
jtourkos added a commit that referenced this issue Nov 4, 2024
jtourkos added a commit that referenced this issue Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

3 participants