First Impressions - BF

Working Groups Attested Network
1

Hi all! I’m coming at this from a broker perspective. I love Bluesky and the idea of the atproto, and have been thinking about how ways Foxy.io (a “small tech”, bootstrapped, site/framework/payment-gateway agnostic platform for custom ecommerce) could help support apps on the protocol. (I co-founded Foxy in 2007. I hope it’s ok for me to reference it in the context of this discussion. Lmk if that violates any rules and I’ll remove any references.)

I’ve been building a proof of concept with Foxy as the broker, so these are my first impressions after spending the past 2 days experimenting.

Three-party attestation: I like this a lot, but I was initially confused because there are 4 parties at the top of the spec: brokers, app devs, recipients, and payers. 3 of those attest, 1 of them verifies (and initiates).

Also, “recipients” are called “creators” elsewhere in the spec (and I’d generally call them “merchants”). “Payers” are called “supporters” (I’d generally call them “customers”). Minor but in the context of trying to understand a full spec, it added some friction for me.

Decoupling payments from apps/platforms: I think this is the most interesting aspect of the spec, and the thing that makes the atprotocol so compelling. Imagine Patreon/Substack/OnlyFans on the atproto, but where creators own not only their accounts and followers, but also their payments.

Maybe the creator wants to accept specific regional payment methods. Maybe the creator’s doing adult content or political speech, and can’t get a normal payment account. Maybe the creator has tax, shipping, discount/coupon/gift card requirements. Find a broker who meets those needs at a fair price, and if things go sideways or their needs change, they can choose a different broker.

This decoupled approach could also allow a podcaster (for example) to control their own payments, while allowing any compatible atproto podcasting app to list their podcasts in the app. The creator doesn’t care which app is used to listen to the podcast, and the app dev doesn’t need to care about supporting all the myriad different requirements merchants have when it comes to payments.

It’s true app devs would have a more difficult time making money off payments, but personally I’d like to see creators have a bit more control than apps/platforms.

Additional (shorter) first impressions:

Recurring billing units: We support day and week. day isn’t very common, but we see merchants use week for consumables, auto-ship, stuff like that. “Every 4 weeks” makes more sense than “every 1 month”. I’d suggest the spec support those units, even if they aren’t common.

Recurring / Scheduled payment failures: I’m still digging and experimenting, but it’s not clear to me how payment failures are handled, and/or how individual payments can be tied to the recurring or scheduled.

Invalidations:

To invalidate a payment, the broker deletes or updates its network.attested.payment.proof record and notifies the recipient. Apps that verify payments will see the proof is missing or marked invalid and treat the payment as no longer active

I appreciate the simplicity of simply deleting the proof, but in the context of the spec, I’m unclear on what “marked invalid” would mean. The “notifies the recipient” might become more clear as I continue building, but if there are best-practices around that, it’d be worth noting.

I’m continuing to work through some unknowns in my proof of concept (like whether/how to best support Foxy updating a seller’s proof, as in the consumables example), but I very much appreciate how this puts creators in charge of their own payments.

The spec looks good. Examples are good. I was able to work through my questions, and I’m excited to continue to poke at it (and more excited at the possibility that this facilitates some really neat atmosphere apps, especially when private content becomes a thing).

Thanks @ngerakines.me. Neat stuff.

7 Likes
2

Hi, and welcome to the forum!

This is neat stuff! How is this different from https://atprotofans.com/ is the data private?

I dont like atprotofans being public data.

I do want to retain user data ownership so that a user can leave an app/project without losing any connections or benefits. So it would have to support permssioned data spaces to never lock the user in.

Could Stratos be use used to provide privacy for creators? GitHub - NorthskySocial/stratos: Shared Private Data · GitHub

See recording on Stratos here: atmo.rsvp

3

I think this kind of decoupling is one of the most powerful benefits of building on atproto.

That said, I’m ambivalent about bringing authoritative payment data or commitments (i.e.: x paid y some amount z). That is what blockchains do, and that risks inviting all the legal, regulatory, incentive, and structural problems of that industry. And if the records aren’t authoritative - if they are cryptographically verifiable but not necessarily true - then it isn’t clear to me what the value of tracking that info on-protocol would be, while it may still introduce regulatory risk.

By contrast, I don’t think this problem exists for on-protocol relationship status (x is a member of community y of type z), which is about communicating the meaning or purpose behind a payment - and allows the payment (or any other means of contribution or validation) to be implied rather than on-protocol. I think this gets at the value while sidestepping much of the complexity and risk (which is what I was trying to capture here).

I spent some time since Atmosphere mapping what I think the minimum viable signal is for this, and have notes as part of the at.fund project here. TLDR - I think there may be very simple ways to get to Pareto value: when both parties agree a relationship (whether associated with a payment or not) exists, it does. If they don’t both agree, it doesn’t.

1 Like
4

sorry I feel like a boomer on discourse. I did not realize this was part of the working group attested.network (which is the new version of atprotofans) - I made a new post with my first impressions.

1 Like
5

Quick followup to my post:

Left out “brokers” = “payment servicers”.

–

@andyschwab.link I think you make a good case, and I’ve been mulling over your first impressions for the past week. I think this tension you point out is worth repeating:

AT Protocol excels at portable, verifiable, decentralized claims about relationships. It does not de-risk financial data custody, regulatory compliance, real-time settlement, or dispute resolution.

Others have brought up saved payment methods, metered usage, trial periods, payment splitting, compliance, etc., but that all feels very much like business logic that I wouldn’t expect any open spec or protocol or blockchain to support.

Like you said, payments are important (and I’d say “important enough to be a major part of the discussion”), but even from my “broker perspective” the payment itself is less interesting (to me) than the trust relationship. Further, the on-proto payment record simply isn’t the authoritative source of truth like it would be on a blockchain. Similarly…

Further thoughts on recurring and scheduled

I’ve been thinking more about the recurring and scheduled records, and I’m not sure I see their benefit, but I’d love to know if I’m missing something. I’ll take the first example from the draft spec of a podcast subscriber.

  • Creator wants to charge $10/mo, so they select a broker and configure their account.
  • App uses the spec to verify the payment/relationship.
  • Customers want to pay $10/mo.

I think that’s a good use case, and simple enough, but I think it’s missing a reality of recurring billing: The subscription only exists in the context of the initiating broker, as the broker has the customer’s payment and billing details. (I don’t think there’s a reasonable way to make payment tokens portable.)

With that in mind, I think the spec is missing some important post-transaction pieces that shine a bit more light on the difficulties:

  • How does the app dev determine access? Say a monthly subscription record has a createdAt of 2026-01-01, and a corresponding oneTime record on 2026-01-01, but now it’s 2026-04-23 and there are no payments since then. Is it open to the app dev to determine if there’s a grace period? (The spec has a “should” for retry logic for the broker, but no guidance for for app devs.) Does the app dev need to account for this “should” logic? What about merchants/communities who want no grace period?
    • An expiresAt on the relationship record (ie. oneTime) would be useful. Also useful for time-restricted permissions without a subscription, which is a valid use case. It’d also be explicit, and easy for app devs to rely on.
  • How does the app dev push the customer back to the broker? Where/how does a customers update their credit card? (Broker.) Pause or cancel their subscription? (Broker?) See their purchase history? (Broker or app dev?) In the above example, the subscriber should be notified that they need to make a payment to regain access, but I’m not clear how that would be handled in the context of recurring or scheduled. In the context of an expiring one-time relationship record, there’s no ambiguity.
  • What happens when a creator/merchant changes brokers? Payment records persist, yes, but a broker couldn’t actually do anything with a subscription that was initiated by another broker.
  • What happens when a broker boots a creator/merchant? No more recurring billing, but the subscriptions could remain?
  • What happens if a creator wants to offer 3 free months to a subscriber? With onetime+expiresAt, pretty easy to do something like “here’s a coupon for a $0 product with a 3mo expiration”, or “I’ve applied a $30 credit to your account (at the broker), which will be used up over the next 3 months of normal billing.” With subs and oneTime records being somewhat detached, it feels a little too open to interpretation.

All that said, the subscription/scheduled records do provide a way for an app to show the customer (and app dev) that a recurring/automatic payment relationship exists. That’s important enough to be a “required” feature imo, but could perhaps be handled by the entitlements (ie. an entitlement for “30 days of access” versus an entitlement for “Monthly subscription”), or an additional to indicate an ongoing relationship.

I think the subscriptions/scheduled records attempt to represent a dynamic resource in a static way. They rely on a specific broker actually doing something off-proto, using off-proto data, and I’m not sure I understand where they’d result in functionality that couldn’t be handled without them.

But I might be completely missing something. Happy to hear other perspectives!

1 Like