xxRFC-2024-001 xxPostage v1.0

Requests for Comment
1

xxPostage v1.0

  • Currently, the xx network doesn’t have the postage system as described in the official whitepaper documents.
  • Users are either in the “free” or “unlimited” group.
  • If you are in the “free” group, there is a limit to how many messages you can send. But if you are on the “unlimited” list, you can send as many messages as you want.
  • The rules for these groups are set by a permissioning server, which broadcasts to all of the gateways about it.

How the “Free” Tier Works

  • The “free” tier limits how many messages you can send over a given time period.
  • Think of it like a bucket with a hole. The bucket can hold up to 1 million messages. Every day, 10,000 messages leak out of the hole.
  • So, if you have sent 1 million messages, you have to wait for some to leak out before you can send more. In practice, free tier users get about 7 new messages to send every minute.
  • If you are on the “unlimited” list, these limits do not apply to you. You can send as many messages as you want.

Postage v1.0 Idea

  • For v1, we will let users pay to be on the “unlimited” list.
  • Users will pay a monthly fee to send as many messages as they want.
  • The current free tier limit will be reduced from an essentially unlimited amount to a more reasonable number to make it worth it for heavy users to pay for the unlimited tier.

Q&A about “text messages” vs “data messages”.

Question: Why would anyone need to make 7 text messages a minute?, and how is that fair to allow that many in a free tier? Who is sending 7 text messages every minute?!

Great question and in order to answer it is important to understand what “Data Messages” are and how they operate in the context of a Network:

Imagine you want to send a large piano from one city to another. The piano is too big to fit in one truck, so you divide it into smaller pieces, pack each piece in a separate box, and send them all to the destination city. Once all the boxes arrive, the piano is reassembled to its original form. In the world of computer networks, this piano is like a “data message.” It’s a piece of information that gets broken down into smaller packets for easy transport and then put back together at its destination.

Social Media Text Message:
Now, think of a postcard you send to a friend while on vacation. It has a short message and maybe a picture. This postcard is like the text message you send on social media. It’s a specific type of information you want to share.

Connecting the Two:
When you send that social media text message, behind the scenes, it’s transformed into a “data message” to travel across the internet. It gets broken down, sent in packets, and reassembled, just like the piano. So, while the social media text message is the content you’re sharing, the way it travels on the internet is through the process of data messaging “data packets”. In essence, every time you send a text on social media, you’re actually sending a type of “data message” on the network, but the content of that message is your social media text.

Thus, messages in the context of the xx network can mean a single social media “text message” if the data of that text message, as a data packet, is small enough to fit into one “data message”. If it is too large or includes a photo, video, or multiple items that are large, it will be broken down into multiple “data messages”.
This is why 7 messages per minute, or something in that range is not unreasonable for a free tier of usage on the xx network, since postage is applied to “data messages”.

Postage v1 Economics

  • The goal of the v1 postage system is extra rewards for network validators based on network usage.
  • As there is no automation at this time, the Foundation will collect the payments and distribute rewards to the validators…
  • The Foundation will also offer a service where users can pay with other currencies, not just the native xx. The Foundation will charge a little bit extra for this service.

Setting the Price of Postage

  • The Foundation proposes to have a set price for unlimited messaging starting at $1/month. This price will initially be controlled by the Foundation and can change in response to how much usage the network receives. If we are flooded, unlimited tier prices will increase, and vice versa.
  • The price in xx will be based on its current market value.
  • If using the Foundation’s currency exchange service, the price might be a bit higher like, for example, $1.10/month.

Summary

The xxPostage (v1) system is a strategic move that will improve the sustainability and economic viability of the xx network. Users will still benefit from the generous free tier, and casual users will only need the free tier to use the network without any friction. Partner projects, professionals, and heavy users can take full advantage of the unlimited tier at pricing that is extremely affordable.

This monetization strategy provides an excellent value proposition for users seeking uninterrupted messaging capabilities and also generates revenue for the network validators. As usage grows and more users start to use the unlimited tiers, growth will ensure the network’s longevity and continuous improvement.

By offering a frictionless currency exchange service, the Foundation will broaden the reach of the xx network to a wider user base, making the network more inclusive and providing another mechanism to fuel growth. In essence, the implementation of the xx Postage system is a logical and forward-thinking step, reinforcing the network’s commitment to providing value to its users while ensuring its own growth and stability.

Onwards,

xx Foundation

3 Likes
2

I kind of thought it’d be $1/10G or somesuch.
If time-based postage is sold, then the price should probably decline towards zero on the last day of every month. This could get complicated…
Say I was elected validator between Sep 10-20. How much do I get from the user who purchased on Sep 15?

  • 5 days out of 30 (1/6th)
  • Divide my cMix rounds for each day by total cMix rounds for the day (so around 1/370th, roughly speaking)

1/6 * 1/370 = 0.00045045 in this case.

Alternatively, make payments T0+30d, send to one big wallet and “leak” 1/30 of the bucket to active validators. That way we don’t have to calculate cMix stats per-validator and monitor who was validator when…

$1/mo for “unlimited” seems cheap, not so much in terms of bandwidth but in terms of storage. (Count the amount of data that can be sent, calculate GB, compare to hosting price per GB - I guess one may be able to send more than storing that data for 21 days cost…). I’d say for $1/mo it shouldn’t be possible to send more than 50% of NVMe SSD capacity.

In other words, if $1 buys me 40 GB/mo, then $1/mo shouldn’t be able to send more than 20 GB/mo, otherwise risk of losing money will become real.
Maybe using a higher limit (but not “unlimited”) would be better at first.

I wonder if you could make an back-of-the-napkin guesstimate how many GB would a DB on each of 370 validators (assuming no changes in set) grow over 21 days, given that each message has 5 copies. Say, if a user sends 10 GB of data, that’s maybe 50 GB over 370 validators or 135 MB per validator.

They’d need to send 55 1kB messages per second to send 100 GB of data in 21 days, but much less if they sent messages with binary attachments (photos, videos). With 5 copies, that’s 1.35 GB per validator - not a problem if there’s 10 of them, but if there’s 100 or 200 such users, it may be a problem…

If using the Foundation’s currency exchange service, the price might be a bit higher like, for example, $1.10/month.

I’d rather keep it at $1/mo and receive $0.9/mo. $1/mo looks good/simple (if they can’t send 100 GB per month; if they can, even $1.10/mo may not be great.)

1 Like
3

Didn’t go into network costs yesterday, so I’ll add another comment.

Take Oracle Cloud for an example. Egress is an affordable $0.025/GB [1]. Very nice, considering AWS is $0.09/GB!

But wait, 10 GB = $0.25.
Assume 55 paying users send 10 GB each and pay $55/mo for it.

  • Disk: total 370 GB on disk (5x) - 1 GB or $0.12 (AWS EBS general purpose SSD) per month or $0.09 prorated to 21d per validator
  • Egress: assuming 3 people per chat, would that amount to 55 x 10 x 3 (egress “multiplier” for group chat) or 1.5 TB / 370 = 4 GB * $0.025/GB = $0.1 (Oracle Cloud). Or $0.36 in AWS.
  • Each validator gets $55/370 = $0.14

Given this scenario (I hope it’s roughly correct), even when AWS is avoided, extra disk and egress costs are $0.19 (Oracle Cloud with AWS EBS-like disk price) and extra income is $0.14.

Yes, there are Tier 3 clouds and home gateways where egress is “unlimited” but we know how those work. (This also reminds me, eventually we’d need to measure how well gateways work, to disincentivize corner-cutting).

This is a simple example and maybe there are mistakes but that’s exactly why I’d like us to work this out - we need to eliminate surprises both for validators and users (we shouldn’t adjust US$ price every 1-2 months and have posts with outdated prices all over the price including social media).

[1]

1 Like
4

A few points of discussion from me:

  • Dynamic pricing - if users are set up with a subscription, it might run into regulatory barriers changing the recurring subscription charge. If they agree to $1/mo and it’s updated to $1.01/mo, they might need to explicitly agree to the new charge.
  • Is the unlimited tier only for private individuals? If an integrator wanted to add mixxing to their app, would they also pay $1/mo?
  • STORJ might have lessons - they do something similar with their node operators. They pay in $/TB for storage and egress, but they actually just pay in STORJ tokens based on the spot price at the time of payment. STORJ is different in that they also pay using the same economy for test data, which we don’t do, relying instead on the validator tokenomics for staking.
  • What we have here is another, separate incentive model for validators. Hopefully it matures to the point where it is also an economic driver for validator participation, but as @rothbardian alludes to above, some validators will pay out the nose for extra egress.

Beyond these points, I think we should move forward with a reasonable plan quickly.

2 Likes
5

I don’t think we can build (at least not now, but maybe ever) any “tiers” - if the wallet address that paid for Postage would have to let some other wallets use it on their behalf. Seems complicated…
At the very least there would have to be a smart contract for X subscribers (wallets) that the controlling wallet would then resell to “end users”. Alternatively, a single-transfer “token” that they could purchase for the month and sell on a Polkadot-compatible DEX.
That seems too complicated for v1, unless there’s a better way. I have many fancy ideas myself, but I think for v1 we should just get the basic low-level elements out and then iterate based on most promising use cases and requirements.

If they agree to $1/mo and it’s updated to $1.01/mo, they might need to explicitly agree to the new charge.

I think they’d buy xx coin for Postage and that would be it - price for the term of subscription has been locked: I understand they wouldn’t buy one every month if they bought 12 at once.
But yeah, it’d be good to know how that’s going to work.
Does one buy xx for 12mo and immediately send all of them to some “credit” address where one month is billed/deducted on the first day and then 11 times on the 1st of every consecutive month?

Also, now that you mention it, subscription should probably be billed in USDC or such (US$, here we go again!).
Because if xx coin exchange rate to USD changes, revenues to validators may grow or crash wildly (as they do now, but at least given current “free” users, the cost of running a node is relatively fixed, which definitively won’t be the case for “unlimited” users who buy subscription precisely because they plan to go nuts on the network).

One of potential challenges I do see is the status of xxF in this workflow. I didn’t want to raise too many points at once, but speaking of potential for buyer vs. seller dispute around pricing and service, my early thinking was to keep it permissionless and not have xxF in the loop.
Of course, that’s easy to say and hard to do, but I thought there’d be a smart contract (say on ETH) which would credit xx Network wallet addresses that buyer provided when buying wrapped XX coins, or something like that.
Having xxF in the loop may turn out be troublesome, as bad actors could simply overload xxF with various complaints (e.g. have users who buy only to ask for the return of coins, complain that unlimited wasn’t really unlimited, etc.).

Edit: “keep it permissionless” = buy/sell coins on a DEX, so that no person or org is in the loop.

1 Like
6

(1) Free tier

We don’t have the first-mover advantage in secure messaging service. How did GMail overcome Yahoo! Mail and Hotmail? Initially, by giving generously. Those times inbox size limits are either 5 or 10 MB. So when GMail was giving 1 GB, we were like, “Who’s gonna use up all that space?”

Seven data packets per minute doesn’t sound generous, but restrictive. Why would people transfer to xxNet when they can do that totally “free” and “unlimited” in other “secure” messaging services already?

Most people use a service due to the network effect. “I don’t really like this messaging app, but all my friends use it, so I’m going to install it.” Or, “I like this app, but none of my contacts are using it, so… Hello xx Messenger, hello Signal…”

It seems we are still ways off of adoption and network effect. This is where we should be focusing, I guess, before thinking about payments.

(2) Paid tier

A few bots flood the network and everyone else pays for it. Not fair. How about multiple payment tiers? Or additional payments per package?The more you use, the more you pay.

Here are examples of this payment scheme:

1 Like
7

They can sure freeload as long as it works.
Signal’s donors spend $20 million a year, that’s why it’s “free”. But that won’t last, although they can keep going for a few more years. Switching cost is close to $0, so all those guys are fishing for donor-style customers.
I haven’t donated anything to Signal and have no plans to do so (maybe I would, but since I’m trying to help xx Network, donating to Signal would only make my own mission harder).

Threema isn’t free and they’re still in business, so I don’t feel bad about the chances of those who charge for messaging services.

Seven per minute may sound little, but if each takes 3 seconds to type, 3 seconds to deliver, and for the other side 3 seconds to read/reply and 3 seconds to deliver, you can’t even send 7 messages unless you cross talk all the time.

Without cross-talk and with almost no thinking time, each user can send just 5 messages per minute.

Messages User Seconds Time
1 A 3 3
Send 3 6
1 B 3 9
Send 3 12
1 A 3 15
Send 3 18
1 B 3 21
Send 3 24
1 A 3 27
Send 3 30
1 B 3 33
Send 3 36
1 A 3 39
Send 3 42
1 B 3 45
Send 3 48
1 A 3 51
Send 3 54
1 B 3 57
Send 3 60
TOTAL: 10 5 per user

If you propose 9 instead of 7, fine: you can send one every 2 seconds, and if that quota includes reactions (the low-bandwidth emoji stuff), I’m okay with that.
But if you’re asking for 20 instead of 7, I’d like to know what is the reasoning behind that idea?

I agree about the tiers. But I would support that in xxPostage v2, rather than overdesign and delay xxPostage v1.

Question for @rick about this part:

The goal of the v1 postage system is extra rewards for network validators based on network usage.

Can you confirm the amount would go to the validator address, and not be split with his nominators? Since the validator pays for disk and bandwidth costs, that would seem reasonable to me.

1 Like
8

But if you’re asking for 20 instead of 7, I’d like to know what is the reasoning behind that idea?

Photos and videos. I wonder how many packets a standard photo these days will take up on xx messaging network. And friends will sometimes send me 15 pictures in one go.

There are also people who act like messaging forwarders. Sending one message they like to 100 contacts. :sweat_smile:

So either those limits per minute be increased, or the time frame be extended. Maybe an hourly limit, or even better, a daily limit. These would better accommodate bursts of messaging activity. The examples I posted above are even monthly limits.

Although one of the points I have in mind in my earlier reply, and this I’d like to emphasize: Fees are a friction to adoption. Fees should come after adoption. At Postage we are taking about fees while few are using xx Network. Or maybe work on it but don’t flip the fee switch yet, just as Uniswap did for years?

2 Likes
9

This is a really insightful comment, i’ll do some work and specify the rough packet size for different types of uploads.

10

In my earlier message I mentioned reactions - that may as well be the smallest message which could be more generous (or use a separate counter in a multi-member tuple counter object).

Personally I don’t find the “need” to send images sufficient for significantly increasing limits.

  • The goal of postage is to attract paying users, not make life convenient for those who want to send attachments for free.
  • Signal has no paid tier. Their goal is to attract as many free users as possible and convert maybe 0.5% to become donors. Their operational (storage and network) costs per user are probably only 20% of ours and our free tier will always be worse then theirs or other messengers that don’t replicate messages several times.
  • It’s an anti-pattern that’s wasteful in many ways (network traffic-wise, premium DB storage-wise, CPU-wise) that has no place inside of cMixx DB.
    • Validators shouldn’t store tens of GBs of memes in PostgreSQL on NVMe and run 4-vCPU gateways to serve that junk
    • xx Network should work with other projects who specialize in blob storage (e.g. Crust, Polkadot Native Storage, etc.).
    • Accommodating binary attachments doesn’t help our ecosystem - it only makes everyone’s text messages more expensive because binary blobs would be explicitly subsidized (it doesn’t matter that bursting takes 50 messages from your hourly quota; the simple fact is most users are unlikely to send 50 messages per hour). We should instead use this opportunity to attract 3rd party ISVs to come up with ways to integrate with Haven or other apps.

The idea for “bursting” itself is fine, even for text messages. But if text messages are the only thing you can send using the Free Tier, one is unlikely to “burst” over 10 messages per minute (if we allowed longer text messages, I’d like bursting for the free tier).

Bursting would be nice for the Premium Tier (if that tier won’t be really unlimited, which is my preference; otherwise there’s no need to manage anything on it, including bursts).

My opinion regarding bursting/throttling:

  • Free Tier: Slow mode and “text messages only” should be in place.
  • Premium Tier: Burst Allowance + Rate Limit should be in place (no real “unlimited” traffic).

Slow mode (rate limiting) works very nicely on Discord, by the way.

https://support.discord.com/hc/en-us/articles/360016150952-Slowmode-Slllooowwwiiinng-down-your-channel

Of course, daily quota from which “bursting” would deduct credits can’t work for the free users, because new cMixx identity is very cheap to recreate. I can send one image, rejoin as a new user, send another, rejoin as a new user, send another…
And the way to “fix this” isn’t to waste time developing against abuse by Free Tier users, but to simply limit the free tier to text messages and spend time on developing plugins for premium members and working with other projects who can address those niche needs which cMixx isn’t meant to solve.

11

I got another idea (posting here for better visibility/backup): Space/channel-based charge:

  • How it works: the first Space admin pays when they create a Space, for example. Can top-up to upgrade for the rest of the month. Blocked users not counted, only joined & not blocked are counted:
    • 10 participants, 10 mps rate limit, text-only, $5/mo
    • 10 participants, 20 mps rate limit, text and attachments, $15/mo
    • 20 participants …
  • Benefits
    • No KYC/AML/DEX/CEX for any participant except the admin who must be reasonably technical in any case
    • May be easier to develop (i.e. accounting for egress, data quantity using Space level stats)
    • People can leave or join as they please - it takes 15 seconds to join and 5 seconds to leave (or be blocked, to release the slot)
    • Better approach for “owner pays” type of private spaces (Support, consulting, etc) - imagine if you’re a shop-owner who wants to provide customer support and need to get everyone to pay xxPostage to submit a scanned receipt
    • Superior privacy for participants (no one needs a wallet, let alone dealing with coins or exchanges) and even the admin who can buy coins via Proxxy/DEX - some learning curve, but reasonably accessible to admins)

I don’t think this makes wallet-based membership redundant, but it dramatically simplifies some use cases where wallet-based can’t work at all. In addition to the examples mentioned above, imagine a family buying 5-person Space subscription - one parent pays, everyone joins and can send photos. Compare that to wallet-based payments where kids need wallets.

I’m curious which approach is easier to develop - it would seem that “Space owner pays” could be easier to develop with (say) a smart contract that drips XX to validators and cMix allows features based on Space program level without doing any queries on users who don’t even need to have wallets.

12

Something to consider, is postage undermining privacy. Since the token isn’t private, is there a risk of associating a message with a user when that user has paid postage?

13

Of course, it’s the same for ENS (Phoenixx) and that’s one of the reasons why I think “single payer” for Space is a great alternative as only the admin - who is likely knowledgeable enough to use Proxxy - could use Proxxy to pay with xx coin and no one else would even need a wallet and know anythingi about crypto.

14

Transmission IDs are separate from reception IDs and not associated with each other.

Which wallets pay is known, but there’s no public tracking of the transmission ID either. Paying only reserves time.

In the future, I would like to improve this in a few ways:

  1. Client can sign in a way that proves knowledge of one of the keys behind a given authorized transmission key, but not which one.
  2. Transmission keys used are ephemeral and rotated out regularly.
2 Likes