What actually happens? (to provoke - and later check - economic interplay with respect to allowed Conditions)?

jMyles commented 1 year ago

The "all you can eat" model has been invalidated.

Given the resounding nature of the conclusion to #3156, namely in the answer, "no", we find ourselves with many useful wagons to hitch, and no obvious oxen up to the job.

The two main control surfaces we have right now that seem to want to grow into revenue funnels are:

AllowLogic
Lingo (with its ever-changing name)

This issue concerns the latter, as the matter of the economic implications of AllowLogic is an ongoing discussion here: https://github.com/nucypher/nucypher/issues/3050

We've also occasionally discussed a third possibility - some kind of authority over cohort parameters ( I believe @arj has done some contemplation on this part) - but this doesn't seem to have gained traction, as there is no clear way to charge for it without the payer being able to resell it infinitely and share the public key(s).

The lower-level representation of the economic activity the DAO captures from adopters

There is already an issue for brainstorming on the high-level models by which our network can generate revenue (ie, the medium-term fee models) here:

https://github.com/nucypher/nucypher/issues/3057

This issue is designed to be more discretely closable: namely in the form of:

What actually happens that causes a moment of economic activity on the network? For example, with Revealer, the collection of the contributions by the beneficary can trigger the 1% flow into the DAO.

And even more distinctly - and this is the closure condition I have in mind:

Where and how does this check occur, and how can we build the interface in such a way that it can be seamless for adopters transitioning from an all-you-can-eat interface in the days of the beta to an action-based model?

We already have Conditions in the AAD. Does the representation of the "Conditions Mode" belong there also?

One obivous quesiton that arises:

Does the "conditions mode" to which the adopting application has purchsed access have a representation that lives, along with the conditions, in the AAD?

One obviously interesting outcropping from this is that Enrico can make any ciphertext he likes - and even those that are unlawful for the paid conditions of the network - and they can later become qualified without further intervention from "Alice" or other machinations of the adopter economy.

It also means that a very clean error message can be given, describing the discrepancy.

It's also possible that we don't want Enrico to explicitly state the "Conditions Mode" and instead to just profer the Lingo, and have the machinery for determining authorization to consist entirely of on-chain checks.

Another example: a marketplace to mint or upgrade NFTs for use with TACo

To drill into another important example and its outcroppings for the interfaces in question:

The pathway I feel emerging for token gating - maybe you do too - is to apply marketplace or wrapping dynamics to tokens before they are valid for use in TACo schemes. This seems to be at least vaguely plausible with no significant logical changes for the encrypting or decrypting parties.

In fact, it may even be an opportunity for a value-add to existing customers: consider an artist who already has NFTs in distribution among a small community; if we build the infrastructure for them to upgrade these NFTs for use as TACoTokens, and it's easy to use, they may well set a price above the minimum (our cut) and use this as an opportunity to generate revenue and metrics from their hardcorest fans.

I propose that we give significant thought to this in a much sooner timeframe than we had previously envisioned.

I also want to keep this issue focused on "what actually happens", with the fee model portions of the discussion remaining on 3057.

So:

What is the abstraction for determining whether a Condition is valid for the level of purchased access? ConditionMode? When is it instantiated? How it is represented? Who can check its validity?
Where is the cannonical representation of this abstraction for the purposes of a given TDR? In the TMK, either as part of the AAD or a separate constituent? Or is it entirely divorced from the TMK, and checked solely as a matter of chain state?

KPrasch commented 11 months ago

This issue it primarily a business strategic decision and design, I suggest relocating it to another repository or knowledge base.

jMyles commented 11 months ago

This issue it primarily a business strategic decision and design, I suggest relocating it to another repository or knowledge base.

That wasn't my intention; perhaps clarification is needed. To my eye, resolution of this issue is a literal API that introspects both the 'mode' of the Condition logic, and also determines whether that mode is properly paid (or whatever economic engagement is required).

nucypher / nucypher