handling casual users (that are not logged in or have no account)

[jellegerbrandy]

Problem: Typical usage of player: watch a video. We do not want to force each new user to create an account before watching a video -t this is obviously too much friction. On the other hand, we do need each player instance to have an Ethereum account. Possible solution is this:

1. User visits page with embedded player
2. If user has an account, the player will find the keystore in storage, and we have our user, and we're fine. (Note though that we assume that the player is always hosted on the same domain - we should think of mechanisms to decentralize that as well)
   3. If no cookie/keystore is found, we transparently (without user interaction) create an account and a wallet. The account is "anonymous" (we can use some cute username generator to generate a name, and we will use a standard (or even empty) password).
   4. The user is at a further (to be defined) point urged to insert a "real" user name, image, and (important) a real password. Behind the scenes: we open the anonymous keystore with the default password, get the 12-word keyphrase, generate a new keystore with that keyphrase and the new password, and remove the old keystore.

[jellegerbrandy]

The last point about "urging" the user to create an account needs some UX thought. When does this happen? When the vid ends? When the user balance becomes non-trivial?

[jellegerbrandy]

@felipegaucho comments: "what if we generate an address, and when the guy will input his data, he's actually a returning visitor, that hadn't logged in for some reason (other machine, I don't know). There should be a way to transfer the "credit/balance" of that session to an existing account by uploading existing login info, right?"

[jellegerbrandy]

Yes. It is complicated/messy.

So the scenario is that there are two keystores: keystore1 that has the keys for account1 that belongs to username on machine1, and keystore2 that has the keys for account2 o machine2 that is still anonymous.

Now how to merge the two? We'd like to reach a situation where all funds of account2 are transferred to account1, and keystore1 is installed on machine2 as well. For that, we can do this (step 5 inthe process):

5. If the user has inserted the data of an existing account, then we ask the user for his OLD keyphrase (from machine1) and (a) tranffer the money from account1 to account2 and (b) throw keystore2 away, and use the keyphrase to generate keystore1 on machie2

This is not so nice :-(

[jellegerbrandy]

Another complication: A user has an account but no cookie. Wants to see a video. We cannot open the existing keystore without the password. What do we do? Option 1: ask the user for a password (which is irritating, because he just want to see the video) Option 2: create an anonymous keystore (now there are two keystores on the machine, and we are similar to step 5)

[jellegerbrandy]

OR (a @eliawk proposes) In all cases: if a user wants to play a video, he is ALWAYS presented with the option "login or view anonymously". @felipegaucho : what do you think of this last idea?

[felipegaucho]

3 .and we will use a standard (or even empty) password)

-> empty would make any anonymous session practically vulnerable till login, no?

The last point about "urging" the user to create an account needs some UX thought. When does this happen? When the vid ends? When the user balance becomes non-trivial?

-> Every paid video asks for acc creation when you click to play (a modal). Non-ppv videos, for anonymous users, bring the "create account" at the end (a skippable modal), from the 1st to eternity, until the user logs in (so he just has the first one hassleless, for now -> we'll refine). That's what we thought for now.

If the user has inserted the data of an existing account, then we ask the user for his OLD keyphrase (from machine1) and (a) tranffer the money from account1 to account2 and (b) throw keystore2 away, and use the keyphrase to generate keystore1 on machie2 This is not so nice :-(

-> agreed, acceptable for now.

(a @eliawk proposes) In all cases: if a user wants to play a video, he is ALWAYS presented with the option "login or view anonymously"

I understand the point of simplifying the flow by deciding login x anonymous from the beginning. But like this it'd be a burden indeed. An alternative approach I've been pondering: what if domains that host an embed of the player straightforwardly (fill in the vagueness) have an account created for themselves (step 3), kept on the domain server, that handles credit/debt of anonymous users, while these users have only anonymous instances that talk to this mother account, and the user has always the option to login and claim back whatever rewards/acc info he temporarily has there ((step 5 above).

Something like outsourcing to publishers the risk / opportunity of "mothering" the activity of their audiences (costs and earnings involved, people who claim back, people who don't, etc). A lot of "if"s, but let me know what you think of the general idea.

[jellegerbrandy]

-> empty would make any anonymous session practically vulnerable till login, no?

well, the keystore is on your local computer, so yo need access to that to open the wallet. So it is not much more vulnerable then the default behavior of amazon or google: you open your browser and you are magically logged in. In any case, the idea is that such anymous accounts will hold little balance, they are like throw-away accounts.

---

About your alternative approach: I think the general idea is sound, and I've been considering the diea as well.

As you describe it, it will not work, but maybe we are using terminology differently: an "account" here is the ethereum address, and a "keystore" is a physical file that contains the information need to sign transactions in the name of that account.

Why it does not work: each player is an autonomous node in the ipfs network, and must be able handle its own accounting with other peers autonomously - ot must therefore have its own filecoin account. Similarly, if a user has rights to see certain vids, this is handled by the Paratii DAO, and these rights will be assigned to his account. So a shared account (or a shared keystore kept on a central server), is not really an option.

What is possible, though, is that anonymous accounts would be controlled by some central instance. So your scenario could work like this: there is a mother account that gives and takes PTI from its anonyous "child accounts" if necessary, provides them with some credit if they need to. And the result is similar to what you describe. This is a possiblity, but I'd try to implement first the underlying logic before moving on to this kinkd of scenarios :-)

[jellegerbrandy]

We have transparent anonymous usage now. Although much of the comments here are still relevant, i am closing this issue in favor of the more updated #248