User should be able to subscribe to paid plans

[holmesworcester]

We will offer paid plans for features that require heavier server resources. This is a placeholder ticket for exploring these paid plans so we can get early feedback.

Overall people understand the flow. The important thing is having premium features that are easy to assess, e.g. not cast in terms of a storage limit that is hard for a user to evaluate.

[holmesworcester]

https://www.figma.com/design/ux7na5q5H8S34vho3NOVcV/Subscriptions%2C-plans%2C-upgrade-server?node-id=13-37&t=y7SCg1irDBgQA4B5-1

[jgaylor]

@holmesworcester I took a quick look at this today organized a few things and made some notes here, but overall I have questions and am unclear about the current scope. It seems we need to account for all user flows across different states (e.g., showing the current plan, upgrade/downgrade options, and management) and ensure they're reflected in the app settings—not just the new member, no server, upgrade flow.

Can we align on next steps on our Wednesday call?

[holmesworcester]

Sure! I think the most important reason to do this work now is to see where the prompt to upgrade fits in and to get feedback on the offerings themselves. Plan management is something we can design when we get closer to actually offering paid plans.

[shibco]

(First post!)

I am coming at this as an outsider, having spent some time meeting up with @holmesworcester in Berlin recently, so please keep in mind that I have little context when reading my feedback.

Open source and distributed platforms tend to try to follow the pricing models and motivations of traditional closed source models. This is demonstrated in this flow, which looks similar to subscription models you'd find in Slack, etc. At the same time, the 'Upgrade Server' button hints at the philosophical differentiator that has not been fully explored here:

At NDC, we've talked about this a lot within the context of popular ActivityPub providers Mastodon and Peertube. We strongly think that in federated and p2p contexts, rather than using the Slack/SaaS pricing models and UX flows for such a project, there exists an extremely promising opportunity to test "perk" based models, such as Discord Nitro or Twitch subs. Unlike traditional SaaS models, this approach to income tends to be:

• on demand
• context-specific and very immediate (server member or viewer motivated in the moment to support the server or streamer)
• contain benefits for both the recipient (a server or streamer) and the sender (the viewer or server member)
• often very successful in practice, and psychologically not as subject to the same decision making processes as a more traditional SaaS pricing flow.

What does this look like in practice? Some initial ideas:

• Calculation tools for server admins to help them price their server's costs (bandwidth, storage, labor, etc) and perks (file size, bitrates, integrations, etc) such that they can make decisions around both via simple pricing models
• Assessing risk of a well-financed adversary using server perks to destroy a community, similar to X's Premium/Verified Bot problem, but specific to network congestion and server noise
• Exploring a legitimate use of cryptocurrency to fund Quiet, where the payment system could be configured to allow Quiet to auto-deduct 1% of each payment to fund development, maybe as a sliding scale for server admins
• Turning features on/off (integrations, app plugins, areas of access) depending on a user's tier of support

[holmesworcester]

@shibco thanks for this! I've thought about Nitro-style "perks" pricing. Where I'm at with this now is, if our users are workplace teams where the organization is paying, Slack-style pricing makes sense. If our users turn out to be more ad hoc communities, Nitro-style and perks / power-ups is what we should explore.

Does this make sense to you? Are there situations where NGO users would be better off with perks-style?

[shibco]

It makes sense to tailor this to the segment of the userbase that is likely to see a large amount of adoption. At the same time - I don't have any solid research to back this up - from anecdotal observation I have seen organisations adapt pretty effortlessly to the model set by Discord. In this case, the organisation figures out that they can use a single account (usually the server admin) to cover the entire server costs via Nitro, rather than distributing the payments across multiple users.

That being said, this is not at all in line with how Discord positions Nitro.

The reason I advocate for this comes back to research we did at Spideroak during the company's 2015-2016 attempt at building an encrypted messenger. We identified pretty common opportunities, where new (particularly savvy) users would create a server and test with friends. The most common pain point at the time was Slack's strange billing UX flow, where users would be punished with CTAs for their server hitting limits, but being unable to make any meaningful changes to the limitations, because billing and server functionality was strictly handled the server admins themselves, via a traditional SaaS model.

I think this is still a problem, and I agree that going all in on the Nitro model is not right either. What could a UX flow that could cater for both look like? The simplest implementation could be a delineation of "Community Servers" verses "Team Servers", and having two approaches to billing. But there could be other interesting ways to handle this too.

@jgaylor at risk of intruding into your work, would it be possible to get added to your Figma team for this project so I can pull together some sketches for your feedback, keeping them within the Quiet project? If you're ok with this, my figma account is [email protected]

[holmesworcester]

It's a good point that a user being able to quickly "power up" the server to unblock themselves if they hit a usage limit is desirable, and that Discord billing sort of contains Slack billing, since in the Discord model an admin can always be the one who decides to pay.

The issue I think becomes the "per seat" model. "Number of users" is very understandable, whereas a limit based on the number of messages or the storage size is hard to understand. This came up immediately and universally in my user research. People did not want to figure out how many GB of messages their community needed.

Do you think there's a good way to do "per-seat" plans in a Nitro-like setting where multiple users can pay? What happens if someone is paying for less than the org is using? Would this get hard to explain?

In an open community setting, of course, per-user is a nightmare because you don't know how many people will join, so you're stuck in a free plan even if you might be able to pay for something. But Quiet will take some time to be ready (feature-wise) for open communities.