Ms Boba (rebuilding community era)

Someone asked how it works, so here's the writeup 👇

As mentioned, if you want to help us get tools like these in fandom's hands, you should support @fujocoded.bsky.social on Patreon www.patreon.com/c/fujocoded

Full post: www.tumblr.com/essential-ra...

"Only bluesky friends (or followers, or mutuals) can access pages on my personal blog" has been achieved internally

(in the example here: github.com/FujoWebDev/f...)

EssentialRandomness - Twitch A (staff) Software Engineer with a passion for fandom, introducing more people to the magic of web development and Astro. Both beginners and advanced viewers welcome!

Today we're extending the Authproto library to allow folks to create pages that are only shared with their Bluesky friends (or whoever else they wish!).

Come on in:
www.twitch.tv/essentialran...
stream.place/essentialran...

@essentialrandom.bsky.social is 🔴LIVE on stream.place! Making friends-only pages in Astro + ATproto!

🔴 LIVE https://stream.place/essentialrandom.bsky.social Making friends-only pages in Astro + ATproto!

a screenshot of a user's slice on slices.network. there is a dropdown that has two items: one item says "fan.fics.work (4)", and the other says "fan.fics.work.chapter (2)". the page itself displays "fan.fics.work" records that were successfully posted through slices.

I'VE CONQUERED SLICES !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

const guestbookTitleSchema = z.string().min(1).max(1000).meta({ maxGraphemes: 500, }); lexicon({ id: "com.fujocoded.guestbook.book", defs: { main: record( "record-key", z.object({ title: guestbookTitleSchema, }) ), }, }); const submissionTextSchema = z.string().min(1).max(3000).meta({ maxGraphemes: 1500, }); lexicon({ id: "com.fujocoded.guestbook.submission", defs: { main: record( "tid", z.object({ text: submissionTextSchema.optional(), createdAt: z.string().datetime(), postedTo: z.string().meta({ type: "at-uri" }), }) ), },

const submissionView = def( z.object({ atUri: z.string().meta({ type: "at-uri" }), author: z.string().meta({ type: "did" }), createdAt: z.string().datetime(), text: submissionTextSchema.optional(), hidden: z.boolean().optional(), }) ); lexicon({ id: "com.fujocoded.guestbook.getGuestbook", defs: { main: query({ params: z.object({ guestbookAtUri: z.string().meta({type: "at-uri"}), showHidden: z.boolean().optional(), }), output: { encoding: "application/json", schema: z.object({ title: guestbookTitleSchema, submissions: z.array(submissionView).default([]), }), }, }), }, });

Since everyone has been posting their own takes on different ways to define lexicons in code (and generate JSON from), here's mine based on Zod.

Just a quick thought dump for a discussion we were having. Should be fairly easy to implement and make typesafe too. It's all things Zod supports now.

an interesting note re: scaling image moderation. in the past 24 hours:

at least 500 thousand images in posts (not considering # of images, just if an image was in the post)
86 thousand avatars
500 thousand url thumbnails
58 thousand videos.

that's a lot to moderate!

build tooling for an SDK for an infra piece that may or may not continue being worth it in the long term, or end up relying on tools that won't integrate with other tools in the future.

I haven't gotten to try it yet (I will soon, I swear, especially if it is all open source), but that's also what made me hesitant about Auth being tied to IAP(?) OAuth rather than the ATproto version. There's no telling how the ecosystem and tools will evolve in the future, and I wouldn't want to

There's also a question of whether I'd need to do modifications. At this point, it's hard to know what I'll need in the future. I wouldn't want to want to end up with divergent needs or timelines, and have to "eject" then. I'd want to know I could run it myself first, so I understand it enough.

For a community project that something I build relies on, I would need to prove to myself that I could switch to a self-hosted version if I ever needed...so I'd start with running one. If I get that confidence and it's a pain to self-host, I might then decide to switch to a hosted version.

I was trying to find the code for the backend (rather than SDK) yesterday and couldn't at a quick glance, so that's definitely good to know. But regardless it's a bit more of a broad point: I trust Bluesky to be around longer because of its shape, but not anything by any of us.

This is exactly it, plus I don't want to be unable to extend it, contribute to it, or even just see what's happening in the code. Especially for this ecosystem, at this stage, I really don't want to be bound to anything that isn't easily replaceable.

Why? Because people only report their enemies, and they report a lot of things that aren't actionable in the hopes of getting their enemies in trouble. The standard industry assumption is that between 90-95% of user reports are reports of non-actionable content.

People once again need to internalize that "generative AI" is a small subset of machine learning, that machine learning is a critical tool that you cannot run a site without past a certain volume Bluesky has long since exceeded, and that it is FAR more reliable than user reporting.

Also, you can't be simultaneously upset that the ML classifier gets things wrong and be upset at the thought of training on user data, because the two are mutually exclusive. The only way to get more accurate ML models is to retrain with real-world examples.

This is going around again and it is not true. Like every site on the internet, Bluesky uses machine learning to do a first-pass approximation of image classification to detect and label content. They have repeatedly confirmed outside services do not use Bluesky user data to train their models.

it's not like people aren't here trying to fix some of those problems by making moderation easier to do at scale in a decentralized ecosystem

Friends, we a cow to cute-ify

bsky.app/profile/bail...

a man is laying on a bed with the words life moves pretty fast on the bottom Alt: a man is laying on a bed with the words life moves pretty fast on the bottom

well we were in @essentialrandom.bsky.social stream.place stream chatting about it and pretty sure that post is your community call now....

And finally, nothing stops a client application from going directly to a user's PDS to get data from them if needed.

There's obviously challenges, but it's far from impossible.

According to where the ban is:
- If the Bsky relay stops serving a records from a PDS, another relay service could replay the Bluesky relay exactly, but add more records in
- If an AppView stops serving records from a user, you could build an AppView that leverages Bsky's and puts those record in

What's this I hear about OpenID but actually good?

Yes! Totally feasible, and at multiple levels according to where the moderation was applied. It doesn't even have to be an alternative "full-stack" solution. Any single part of the protocol stack can do some version of this.

lmao no worries! Graze Social PBC officially releases the name Moolissa for any cow based brand to use, this is an official statement

"Are we going to talk about the drama?" (chants) I'm a strong woman who cannot be baited into commenting on discourse... I'm a strong woman who cannot be baited into commenting on discourse... I'm a strong woman who cannot be baited into commenting on discourse...

EssentialRandomness - Twitch A (staff) Software Engineer with a passion for fandom, introducing more people to the magic of web development and Astro. Both beginners and advanced viewers welcome!

Today, we're cleansing the ~bad vibes~ by helping folks with some of the ATproto work they're doing, from writing articles about how it all works for fans (bluedreaming.dreamwidth.org/75226.html) to fanfiction Lexicons 👀

www.twitch.tv/essentialran...
stream.place/essentialran...

people are disconnected from how tech works... they're disconnected from how capital works.... they're disconnected from how community works.... it be rough out there, man