Post

I've had an idea around this area for the past 18 years, and I've never figured a way to crack the nut open. I think you're on to a few key ideas with the twenty cent article, that's where I've been focused on a lot of my thinking.

Dare I say...micropayments.... Such a tough nut to crack, but I think the timing might finally be right with SaaS/subscription fatigue, open payment rail regulatory maturity and permmissioned data on atproto.

Yesss love it, I do! (And want all y'all to make $ here too in all sorts of ways!) Pairs pretty well with my recent post/talk, I kept it high level & didn't get into monetization details, this is really good & I want to explore lots of what you talk about around $ interop and permissioned data

brendan@schlage.town

My talk from last month's @atproto.nyc, on Atmospheric Stacks! How the Atmosphere can compete with incumbents like Substack — not by recreating 'em app for app, but by replacing 'em collectively, as an ecosystem. With @leaflet.pub & @standard.site as case study + expanded with a few *addenda* :)

Definitely pairs well! I love the notion of stacks. I should’ve mentioned your post in there, might squeeze it in. I have a lot more to talk about RE spaces and payments - veryyyy soon

Niceee may be some time til I can dig in more (out on parental leave starting now) but hope you can jam on all this w/ Jared & Celine soon :D

> Does a moderation service need to operate alongside a client, AppView, ad network, or marketplace so the value it creates becomes economically legible? I know moderation for communities is on Bluesky and @brittanyellich.com's mind, but I don't know if they've thought much about the inverse case.

It might be too intrinsically tied to the AppView in its current form to allow moderation services to be permissioned, paid services. Worth thinking about though!

Yeah my thoughts exactly - what I'm alluding to with the 'collective markets'. Seems like the AppView allows for a viable product and moderation is part of making that product valuable.

From you I was curious if you’d thought about it wrt like, technical feasibility, I guess? Like users can subscribe to any labeler to see the labels. Could the ability to see those labels be gated on membership into a member space? (I have yet to fully read the diaries or start a labeler yet lol)

Ah, that's a good question, but I don't think so? AFAICT, apps typically cache the labels emitted by a labeler. When a user subscribes to a labeler, the app will then decided to show the labels from that labeler to the user. I don't think there's an opportunity for spaces to be injected there.

Loved this post. For it to work, don't you need to track which app/service created a record? If an app provides discovery to standard site publications but writes a generic standard site sub record, there's no way to identify who generated the subscription. How can you share the payment?

We know who creates what content, i think the downstream relationships can be figured out by knowing where a transaction occurs and what services grant entitlements based on those transactions. Great question!

I’m thinking more along the lines of knowing which services capture value - something that is much easier to record through the proposed payment layer. More to come @atmosphere.money ! You’re right right now there’s no uniform created by pointer, but that’s possible too!

I'm new to all this and still learning. I imagine it's been discussed by smarter people. I'm just craving some sort of createdBy-type pointer to whichever service or app generated the record. Would need verification, which complicates matters, but it seems necessary for splitting payments?