bryan newbold

@bnewbold.net

5570

Followers

839

Following

3060

Posts

dweb, cycling, snow, big cities, wiki. I like speculating about found objects.
protocol engineer @bsky.app. formerly archive.org
elsewhere: bnewbold.net / @[email protected]

Posts Replies Media

Reply to

austin

the AppView needs to be able to make an inbound websocket connection to the labeler service (Ozone instance). you could try ngrok or similar. common issues are reverse proxy (like nginx) not having websockets enabled by default, or TLS certs not being set up. there is a debug command in ozone repo

Reposted by

bryan newbold

the chessthread starts here reply with algebraic chess notation to play

Reply to

Ryan

that looks right! sorry, dropped the ball on getting these better written up. you can do just #identity and #account; #handle and #tombstone are deprecated

there are also the new account status API endpoints to implement, which should return the current account status for any hosted DIDs

she Quee on my Queg til I rum

Reply to

Kuba Suder 🇵🇱🇺🇦

(this wasn't in reaction to anything you said, it came out of a separate discussion realizing we haven't re-clarified this and some other points)

we can chat, but there are a bunch of public tools already built around blocks. if folks "could just not" that would be great, but we mostly want to find a solution so blocks are not public

Reply to

dr. e. katherine

yup! we have thought and planned a lot around privacy and public content reuse since the beginning. and have read and spoken to a lot of external folks.

we are pretty aligned with "the public web". there are a lot of media and communication systems out there in the world: this is a very specific type with a lot of known and ever-evolving risks, upsides, and downsides.

many folks in recent years are moving away from this type of system, and I think they have great and very legitimate reasons. but "public web" and "global public broadcast" still have a very important role to play in the world.

Reply to

7fqx ☘

it is a great article! in particular I think a lot of the ideas in both nostr and atproto come from SSB and prior systems. atproto was also pretty informed by ActivityPub; I don't think there was much direct atproto/nostr cross-pollination, though there has been interest in the labeling system

Reposted by

bryan newbold

Can we get a retrospective on how well Bluesky has accomplished these goals so far? Just wanna see what people think

A Self-Authenticating Social Protocol - Blueskybsky.social Bluesky’s mission is to drive the evolution from platforms to protocols. The conceptual framework we've adopted for meeting this objective is the "self-authenticating protocol."

👀

"assume everybody knows this but just in case": we think public blocks and enumerating/policing block behavior are bad! the reasons they got implemented that way are serious, but we bemoan and brainstorm fixes around this endlessly

seeing some networking disruption impacting a big fraction (but not all) users, "re-routing"

Reply to

Nick Gerakines

we are definitely looking at better ways to integrate new Lexicons in to the bsky app and feeds! the post "embed" type gestures in this direction, but doesn't quite work right now. some workarounds right now:

if you have a web interface for event content, can have folks link to that web URL and do an open graph link preview card. you could create an app.bsky post record that corresponds one-to-one with each event record (same repo, same rkey, different collection) and track "likes", replies, etc

the challenge is symmetric: how to integrate bsky posts in to other apps/modalities/lexicons? eg, where and how does the code live to render an "embed" post? could change over time; eg we are likely to add video, embeds would need to be updated to render that

Reply to

drew mca

those routes mostly get proxied (controlled by a client header). at least for now, basically all requests go via PDS for auth, but arbitrary thoughts can go to arbitrary providers/servers

there is some legacy code in the typescript implementation. partially cruft, partially doing some "read after write" hacks. we are designing a more generic solution for the later, but it isn't a blocker for building new lexicon apps today

Reply to

drew mca

it is mostly the appview that handles app.bsky.* records. the idea is that when creating a new app with new lexicons, you need to implement and run an appview (for just those records), but not PDS

Reposted by

bryan newbold

First blog post is up!

Hello World | Smoke Signaldocs.smokesignal.events Introducing Smoke Signal Events, an easy to use event and RSVP management system built on top of atpoto.

Reposted by

bryan newbold

Hey, a reminder I give people every now and then: a friend of mine got blackout drunk and emailed Bush on the night of the 2000 election and said “I’m going to kill you and you’ll never find me.” Six hours later he was in cuffs and it cost him thousands in legal fees and he’s still on a list.

reminder that this is a public network, don't say anything stupid

Reply to

Rudy.

yeah, we definitely need to make that possible. going to take some thinking

so you think it would be sufficient if there was a gradual path to migrate a feed off a personal account to a service account. eg over a couple days, when not even planning to deactivate. or does it need to be an immediate any-time transition option?

Reply to

Coyote ^.^ ΘΔ

things like spam, bots, obvious harassment, slurs. mostly flags for human review ("auto-report" not "auto-action"), but some behaviors just after account creation get auto-actioned, and it was the "is this account brand new" logic that broke

we have an automod bug where some random accounts are getting hidden by mod service accidentally. on the order of a couple dozen accounts. fix going out soon, and all labels will get cleaned up

god damn it people

Reply to

Anil Dash

thanks for sticking with it Anil!