The section title is "Arrests are shifting from criminals to non-criminals" (all unauthorized immigrants, criminal are not), and the text of the section supports this thesis except that one sentence which shifts unexpectedly from the criminal/non-criminal to the authorized/unauthorized axis.
You do touch on the authorized/unauthorized distinction later (restrictionists wanting to reduce immigration overall), but dropping it into this sentence breaks the logical flow.
Because that's the bait-and-switch axis your whole piece is about. The public story is “we're removing criminals,” but enforcement is increasingly hitting people with no convictions.
We are about to find if we are intelligent enough to create a computer program that is intelligent enough to create a computer program that’s more intelligent than we are.
Yes I'd love to talk to you about how your are implementing community notes in your app.
Great post as usual Jonathan.
By the way I think found a small error:
"Part of what is going on here is that a vocal Red minority want to restrict immigration generally, unauthorized or not"
I think you mean to write something like:
"unauthorized immigration generally, criminal or not".
Either ICE has started cruelly arresting beloved community members, or ICE is merely enforcing existing laws to remove murderers and rapists.
Both of these are only half-right. Whatever side you’re on, you probably have something to learn.
www.betterconflictbulletin.org/p/annoying-f...
Thanks for the suggestions! Here's the link to the post on the forum: discourse.atprotocol.community/t/lexicon-em...
Thanks @erland.sh. I posted an updated proposal to @bmann.ca Lexicon Embeds discussion.
discourse.atprotocol.community/t/lexicon-em...
I've recently been thinking along similar lines:
bsky.app/profile/jona...
@bnewbold.net , @pfrazee.com, @alex.bsky.team check out this proposal for oEmbed support in other ATProto lexicons! It builds on lexicon publishers for web embeddings. Thoughts? Should I post this somewhere? #atproto
Alternatively, to keep web stuff out of schma defs, this could be a separate record, e.g. com.atproto.lexicon.web.
So if you use a lexicon you don't control, you'd have to really trust the publisher. But that's already the case.
Thoughts anyone? Could this work? What should I do with this?
(8/8)
So for example, the schema record for app.bsky.feed.post could be updated with an optional "web" field, like this:
{
"id": "app.bsky.feed.post",
+ "web": {
+ "url_scheme": "https://bsky.app/profile/{DID_OR_HANDLE}/post/{RKEY}",
+ "oembed_api": "https://embed.bsky.app/oembed"
+ }
...
(7/8)
oEmbed works with HTTP URLs only, so the lexicon publisher would need to provide information to map an ATProto record to an HTTP URL (a nice bonus).
This information naturally should be published in/alongside the com.atproto.lexicon.schema record.
(6/8)
The Lexicon publisher? This makes the most sense. For example, Bluesky authored the app.bsky.feed.post lexicon and are the authority on what a Bluesky post should look like. And indeed Bluesky already hosts an oEmbed service for Bluesky posts.
(5/8)
The PDS? "This is how I want my personal posts to be displayed." No, this is not a personal decision -- there should be a standard for how Bluesky posts are displayed.
The App View? "This is how to display posts you fetch from my app view." Hmm, no, that's not the App View's role either.
(4/8)
- Who should host the oEmbed service that knows how to produce oEmbeds for an ATProto record of a given type?
- More specifically, who should decide how, visually, an ATProto record of that type should be displayed?
(3/8)
Allow a com.atproto.lexicon.schema record to include an optional config that tells how records of that type can be displayed on the web. It should include 1) a scheme/template for converting an ATProto URI into an HTTP URL and 2) an oEmbed service URL.
Here's the line of thinking:
(2/8)
I've been thinking about how oEmbed could work for ATProto records.
Currently, you can embed a Bluesky post on any website by passing the post's bsky.app. URL to the oEmbed service. It would be nice if you could also embed records from other ATProto lexicons.
Here's a possible solution...
(1/8)
I bought my ticket to #ATmosphereConf - join me in Vancouver March 2026 atmosphereconf.org
beautiful!
Yes it’s true, Bluesky controls what users of the Bluesky app see, which means they control what most people on the atproto network see. But it’s still possible to build atproto apps that are totally independent of Bluesky. Of course, it is possible nobody will use many of those apps…
I see your point. But Bluesky has actually made a point of making it possible to build on ATProto while being independent of Bluesky.
$3/day is not much for a well-funded project. There are probably projects that are already doing embeddings on the entire firehouse. But once you add images and video, or larger models, costs could easily increase by orders of magnitude. Then the economics of a shared service makes a lot of sense.
Would anyone be interested in an ATProto embeddings API service? I calculate it would cost maybe $3/day to produce embeddings for every post using OpenAI's text-embedding-3-small.
But this cost could be shared, so an "embeddings firehouse" could cost each customer just pennies a day.
Ahah! Thank you that clarifies things for me.
Another takeaway from @eurosky.social live conference in Berlin: @rose.bsky.team says Bluesky does not hate advertising.
@sherifea.com and @seabass.bsky.social just demoed EuroSky’s moderation infrastructure.
But I'm wondering: how much of this work must be replicated?
Bluesky must comply with the DSA for EU users, and they already run a labeler for the posts distributed through the Bluesky app...
#euroskylive
@eurosky.social conference in Berlin just finished. One of the main themes seemed to be European independence from US big tech companies. Including from Bluesky. #euroskylive
Looking forward to attending @eurosky.social on Nov 19th in Berlin. Anyone that wants to meet to talk about Community Notes for Bluesky and @bluenotes.social let me know.
