PiPup 🎄
@pipup.social
Try: pipup.social
Your blog with markdown, code, math, diagrams, music notation, embedded web media, uploaded photos, spoilers, light & dark modes.
Built on @atproto.com. Bluesky replies are blog comments. Our feed also shows Leaflet and WhiteWind posts!
Your blog with markdown, code, math, diagrams, music notation, embedded web media, uploaded photos, spoilers, light & dark modes.
Built on @atproto.com. Bluesky replies are blog comments. Our feed also shows Leaflet and WhiteWind posts!
and follow-up by @graze.social
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...
pipup.social
December 7, 2025 at 2:57 AM
and follow-up by @graze.social
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.
December 6, 2025 at 6:48 PM
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.
December 6, 2025 at 6:42 PM
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.
December 6, 2025 at 6:27 PM
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.
December 6, 2025 at 1:18 AM
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.
December 6, 2025 at 1:13 AM
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
- a record representing a post
- a `title` field
- an at uri field
1/2
December 6, 2025 at 1:08 AM
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
- 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.
December 6, 2025 at 12:38 AM
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.
December 6, 2025 at 12:05 AM
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
December 5, 2025 at 11:58 PM
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
December 5, 2025 at 11:57 PM
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
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.
December 2, 2025 at 10:52 PM
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 🤔
December 2, 2025 at 10:39 PM
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 🤔
I'm tempted to do this myself but don't have the bandwidth (no pun intended) right now.
November 21, 2025 at 3:26 PM
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.
November 21, 2025 at 3:21 PM
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.
I try to keep this one up to date.
AT Protocol apps + lexicons
docs.google.com
November 20, 2025 at 7:00 PM
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.
November 19, 2025 at 6:08 PM
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.
😃
😃
November 19, 2025 at 6:04 PM
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.
😃
😃
We use markdown and also have support for several extensions like Mermaid diagrams.
November 17, 2025 at 10:01 PM
We use markdown and also have support for several extensions like Mermaid diagrams.