My other hot take is that the community stuff would benefit from active outreach before working to finalize it. We've thought a lot about what sub-groups look like for Roundabout, but haven't had the resources to engage – I don't think subgroups-in-spaces will factor into our implementation at all.

Without some sort of abstraction that elegantly handles that, I think whatever the motivations, folks will gravitate towards one or the other (and the one will be spaces, because most use cases require spaces at some level).

I think it'll just come down to the simple fact that all of our indexers now have two code-paths and two separate sets of semantics to track for data that's arguably "the same."

The one thing that's already super annoying that we've already discussed is the fact that now we have multiple synchronization mechanisms for data that is possibly otherwise the same. Strengthens my theory that everything will just move to spaces, rip the firehose.

The more we've been discussing this and putting into production, the less you're going to want to hear our feedback. 😂 (Don't worry, it'll work, but a healthy dose of yagni would make it better, I think)

Apple and Google have so much to answer for their continued support for in-app browsers like that. In 2009 it was barely defensible on performance grounds, when app switching took ages. Now, it's just 100% enshittified anti-user garbage. 😢

I don't disagree and also... One of the things we see really clearly w/Roundabout is that a huge amount of our traffic ends up in Meta's embedded roach motel browser. Sadly, aggressively pushing an app is the only way out of that. We do email drips, etc, but those end up in other embedded browsers.

It weighs heavily on the soul

Renewing my call for email portability.

(the problem with having separate buttons is that we generally want to discourage the use of direct replies, except when there's actually something to keep off community channels; it's a < 0.5% use case, so giving it a 50% UI affordance wasn't the right call for us)

Given the local context, we can also conceivably have a database of all local public business contact information, and allowlist it.

We're also operating at a local scale so it's relatively easy for stewards to intervene if there is something that slips through, and the blast radius is much smaller than with traditional open networks.

We don't allow PII in public posts; the labelers block it, but offer the option of a direct reply. The biggest challenge is distinguishing between public data that looks like PII (business addresses/phone numbers) and personal private data. So far, the results are promising.

Thanks! No prior art that we're aware of, but would love to know if anyone finds others working on similar approaches!

In practice it behaves much more like a fancy "semantic regex match" than an opinion generator. We started trying to use frontier models to do the same, and the results were just okay. So far our experience with the zentropi models is vastly better.

The zentropi models return a mostly-deterministic boolean plus a confidence float for a given input, not a generative result. Most folks' experience with LLMs is as bullshit generators, whereas the model we're using is tuned (and re-tuned as necessary) to reliably give us a narrowly defined label.

Thanks! 💖 Currently it's off-protocol, but only because we didn't want to gate the feature on migrating all of our PDS repos to spaces-capable ones. We fully intend to migrate the feature to a spaces-based implementation once the infrastructure is in place.

For coordination around posts like "I've got a free table!" this is perfect. Most importantly, once the interaction is done the thread can be closed off. That means no ongoing surface for abuse, and no new DM platform to worry about. Building things for people's actual needs feels great. 💖