Enhancing the Awareness, Utility, and Anonymity Set of Oxen - Part 4 - Promote ‘Perfect Forward Secrecy’ Purchasing by Invisible Social Graph Exploitation and Interactive In-App Prompts

[venezuela01]

Enhancing the Awareness, Utility, and Anonymity Set of Oxen - Part 4 - Promote ‘Perfect Forward Secrecy’ Purchasing by Invisible Social Graph Exploitation and Interactive In-App Prompts

The ORC-8 discussion illuminates a critical concern within the Oxen ecosystem: underutilization of the coin owing to a limited number of daily transfers, which in turn diminishes Oxen's practical anonymity set.

As foundational tools, we've utilized the AARRR framework and previously presented strategies in:

• Enhancing the Awareness, Utility, and Anonymity Set of Oxen - Part 1 - Web Traffic Optimization
• Enhancing the Awareness, Utility, and Anonymity Set of Oxen - Part 2 - Oxen Airdrop for ONS (Session User Name)
• Enhancing the Awareness, Utility, and Anonymity Set of Oxen - Part 3 - Promoting ONS Purchasing through Invisible Social Graph Exploitation and Interactive In-App Prompts

These strategies primarily stimulate 'Acquisition', 'Activation', and 'Referral'.

In alignment with Part 3, this proposal also seeks to enhance ‘Referral’ via a similar methodology. While Part 3 is technologically feasible and relatively inexpensive to implement, serving as a low hanging fruit, the features 'Sending a message request' and 'Accepting a message request' are infrequently utilized, limiting their overall user exposure and subsequent conversion potential.

Contrarily, Part 4 hinges on the yet unimplemented and technologically challenging Perfect Forward Secrecy (PFS) security enhancement design. PFS was preliminarily proposed in Session Standard: 1-1 Chat Security Enhancement with Perfect Forward Secrecy and has been implemented in widely used secure messaging apps such as Signal.

Due to inherent technical challenges in a decentralized network, it's nearly impossible to design a PFS protocol with multi-device syncing support unless both parties have registered a 'Primary Device' as proposed in Session Standard: 1-1 Chat Security Enhancement with Perfect Forward Secrecy. This necessitates the purchase of ONS mapping from Session ID to a primary device ID.

While this might seem like a limitation at first glance, it's actually a potential advantage: as the famous quote suggests, "it's not a bug, it's a feature."

Contrary to 'message requests', regular 1-1 Chat is frequently utilized by users. Thus, if we integrate an interactive prompt that triggers whenever a user capable of PFS is chatting with a user who lacks PFS, we can effectively encourage the accounts with lesser security capabilities to invest in a one-time purchase of the 'Session Standard' security enhancement package, which includes PFS, so both party can be protected by PFS. This is an all-or-nothing feature, where either both parties possess PFS or neither does. Hence, if one party has the potential to activate PFS, it becomes an obligation for the other to make efforts to keep pace, to avoid compromising their counterpart's security.

We can effectively craft the message as "Friends don't let friends chat without PFS", thereby fueling a potent viral marketing strategy. Leveraging the invisible social network within Session, this approach has the potential to engage a substantial portion of our user base.

We purposefully employ the term 'Session Standard' to distinguish it from 'Session Pro', creating three incremental pricing tiers: 'Session Free', 'Session Standard', and 'Session Pro'. 'Session Standard' offers a one-time, low-cost purchase that significantly enhances security, while 'Session Pro' is a monthly subscription offering timed feature enhancements.

This 'Session Standard' package also includes another security enhancement feature known as Multi-device Security Enhancement, which will be revisited in a forthcoming proposal.

[KeeJef]

My general feeling is to be against requiring payment for features which provide enhanced or perceived enhanced security, this however is a tricky subject, and depends on how "essential" the feature is considered.

There is a careful balance to be struck to ensure that free users feel they are getting the required features to keep them engaged in the application and monetizing features for powerusers. My gut feeling is that monetizing PFS, which many users would feel was a core security feature would imbalance paid and free users.

[venezuela01]

My general feeling is to be against requiring payment for features which provide enhanced or perceived enhanced security, this however is a tricky subject, and depends on how "essential" the feature is considered.

There is a careful balance to be struck to ensure that free users feel they are getting the required features to keep them engaged in the application and monetizing features for powerusers. My gut feeling is that monetizing PFS, which many users would feel was a core security feature would imbalance paid and free users.

Yeah I also agree that this is a tricky subject and I share your concern as well. It's good to raise some discussion anyway.

[venezuela01]

My general feeling is to be against requiring payment for features which provide enhanced or perceived enhanced security, this however is a tricky subject, and depends on how "essential" the feature is considered.

There is a careful balance to be struck to ensure that free users feel they are getting the required features to keep them engaged in the application and monetizing features for powerusers. My gut feeling is that monetizing PFS, which many users would feel was a core security feature would imbalance paid and free users.

I think this is a really good point so I have reflected on it again and again. This led me to wonder: What if the fee for PFS were nominal? Considering it's a one-time charge in the proposed design, if we set the cost of on-chain registration for a primary device plus PFS to a minimal amount, say $1 or even $0.2, it will be the users responsibility to decide whether or not to enable enhanced security for a modest fee. The charge for primary device registration coupled with PFS isn't meant to be the primary revenue stream for Session monetization. Instead, it serves to deter spam on the Oxen network and to motivate users to begin using the Oxen wallet. Given the fee's modesty, a user without any Oxen token might even ask a friend to cover the cost, ensuring their protection via PFS. This approach would also enhance the utility of the Oxen token as a medium of exchange. We could prompt this in-app, "Your friend is not protected by enhanced security. Sponsor them with $0.2 so both of you can benefit from PFS protection".

It's understandable that some users might create multiple accounts, with some accounts being disposable and not requiring enhanced security; some other users might just try Session for fun without substantial usage. However, for long-term users who are serious about privacy and security, they are likely willing to pay a small fee for enhanced protection of their primary account.