We support logos, including AWS. Is there a specific icon set you’d like to see?

Great to see more interest in the Fountain format! I knew supporting it would help us bring more writers to atproto so seeing other apps use it is very encouraging.

How Graze Sent 24.5b posts to Bluesky in a year on Clickhouse How Graze Sent 24.5b posts to Bluesky in a year on Clickhouse ![](https://leaflet.pub/api/atproto_images?did=did:plc:i6y3jdklpvkjvynvsrnqfdoq&cid=bafkreicqb6qoe...

and follow-up by @graze.social

Good write-up by @bnewbold.net about indexing atproto data at scale.

But I suspect the feedback you'll get from users is that they like having all blog posts in one place but want to be able to read them in one place too.

I guess you could validate the idea by building the preview service with 4 or so existing longform lexicons "manually" extracting the metadata and see if it gets traction with users.

It doesn’t seem to me that an additional record for post metadata is the right design. It would have to be added by all platforms on all new and old posts and the benefit is making it slightly easier to build a preview-only listing service that I don’t think users will want.

Feel free to give PiPup a try. Happy to answer any questions.

Though I see somewhat limited value in only being able to render previews and a link to the post on the original app. Going all the way transforming and indexing the content seems like a better experience to me for the end user though admittedly harder to implement.

Got it. I'm more of the idea that a very small set of standard fields could be agreed upon for inclusion on the original record rather than a new record. Something like: we all agree to have
- a record representing a post
- a `title` field
- an at uri field
1/2

I can see how it would help discovering when a new longform lexicon has appeared in the firehose. It wouldn't be able to tell a developer how to validate, index, or render a specific type of post though, correct? I guess I need to see an example to visualize the goal and how it would be achieved.

forgot to mention an important note: in order to maintain only 1 renderer/editor, updates of other lexicons come through the jetstream and are applied to the index. They're not done on our editor which is markdown-only.

At render time all posts look the same as they've been processed and are all markdown now. 2/2

Hi! Happy to talk about interop. My current approach: I index 3 lexicons taking advantage of the filtered jetstream (2 use markdown, 1 uses blocks so there's a translation layer). The lexicon itself tells me what the translation layer needs to do to validate and transform to markdown. 1/2

Can't reply so hopefully you don't mind the quote. Using a community lexicon was my original intention but there was never agreement on what longform should look like so there's no community lexicon for markdown. For example, some want markdown as an attached blob, some (like us) as text.

I guess it wouldn't be the end of the world if we also do this for other domains and just clarify in the Terms of Service that you won't use this feature to copy someone else's writing and pass it as your own. We already have a similar authenticity provision for auto-generated text.

I've been thinking about different ways of importing a blog to atproto. Your case is really nice because your handle is the same as your blog domain so we could give you a 1-click import of the RSS feed into your repo knowing the blog belongs to you. For other cases there are tradeoffs to consider 🤔

Today we're grateful for community and the tools that allow us to share knowledge and lift each other up. Happy Thanksgiving!

Interoperable Atmosphere apps with Lexicons: Lexicons create a shared language for apps on the Atmosphere Interoperable Atmosphere apps with Lexicons Lexicons create a shared language for apps on the Atmosphere A fundamental problem with traditional social apps is...

Great piece on atproto interoperability from @jimray.bsky.team.
Common schemas unleash innovation without need for permission from any central authority!

I'm tempted to do this myself but don't have the bandwidth (no pun intended) right now.

Building a self-hosted solution is very doable. There are so many pieces of this that are solved with managed services: transcoding, adaptive bitrate streaming, object storage, CDN, ad-insertion, etc. It's just a matter of finding someone who's not already working on too many projects.

Week 5: Quality of life, friction, papercuts... Week 5: Quality of life, friction, papercuts... In this business, we have a lot of ways of saying "hey, you know this kind of sucks, right?" I like to think of...

Going to Production and other super useful atproto resources here from @alex.bsky.team.

AT Protocol apps + lexicons

I try to keep this one up to date.

For apps that can't share lexicons, translation is a great option and that's why we support both WhiteWind and Leaflet posts. So you can catch up on your favorite writers in one place regardless of where the post originated.

There's a docs.bsky.app/blog for @atproto.com and a bsky.social/about/blog for @bsky.app. I may be biased but I think PiPup would be fantastic, especially for the technical one.
😃

Us!

We use markdown and also have support for several extensions like Mermaid diagrams.

If you have a technical blog on a centralized platform and you'd like to bring it here, I'd love to hear about your needs. How can we help? What features do you value or are looking for?

#blog #atproto #dev #indiedev #gamedev #webdev

Welcome to the #atdev community!

This is not to say one can't scale a relational db, of course. But once you find yourself doing your own artisanal sharding it's a clear sign it's not a good fit for your use case and you need a model built for partitioning data.