earthbasetwo.net @earthbasetwo.net · 04/10/2026departuremono.comdeparturemono.comDeparture MonoA monospaced pixel font with a lo-fi, techy vibe. 051
earthbasetwo.net @earthbasetwo.net · 14/09/2026What's cool about this is that it means you get AT Proto's portability baked-in to both where the data actually lives (in a PDS) and where the content lives "on the web". 020
earthbasetwo.net @earthbasetwo.net · 14/09/2026An AT Proto-based client could direct browsers (or any client appropriate for the content type) to their current location. Basically AT Proto as an address space over your web-accessible content. 130
earthbasetwo.net @earthbasetwo.net · 14/09/2026Working with @standard.site more, I'm getting a better understanding of it's intentions and uses. An interesting thought: If you define your site's structure and content on your PDS, you can actually change the web addresses, including domains, of the content. 160
earthbasetwo.net @earthbasetwo.net · 10/09/2026I think multi-app functionality is cool, and I do think there is a way to enable multiple-app functionality on a single pos here. This confirmation of the intentions here helps to define that in a framework-compatible way. I'm going to shift some models in our experiment and see how it goes! 010
earthbasetwo.net @earthbasetwo.net · 10/09/2026Ah I see. So your intention is a bit higher level than I was thinking. standard.site should enable processing only on the specific fields it implements, with optional app-specific behavior on a one-per-document basis. Thanks for the reply! 100
earthbasetwo.net @earthbasetwo.net · 10/09/2026So I am wondering if you can help me understand your intention regarding sharing site.standard.publication and site.standard.document across different apps? How do you envision this being used? Why is it better than each app defining its own lexicons from the base? 110
earthbasetwo.net @earthbasetwo.net · 10/09/2026But 'content' and 'links' are both single objects - not arrays. So once you create a site.standard.document from App A, which overrides the 'content' union type, it is intrinsically tied to App A - only by understanding App A's content lexicon can App B do anything meaningful with the document 110
earthbasetwo.net @earthbasetwo.net · 10/09/2026What I was hoping for is that App A can do this, and App B can also add its own custom data, also to 'content' or 'links'. Each app would only know about the base model + it's own data. But you could share base display/edit functionality. Different views on the same data highlight different parts 110
earthbasetwo.net @earthbasetwo.net · 10/09/2026So it is clear that any app can create a site.standard.document, along with it's own custom data e.g. in the 'content' or 'links' fields, and any other app could read the basic parts of the model ('title', 'description', 'textContent') and display those 110
earthbasetwo.net @earthbasetwo.net · 10/09/2026@standard.site I'm working on an experiment/project with @ken.wzrdz.cool and we have some questions about your intent regarding cross-app sharing of your generic data models. I'll post a bit in this thread: 221
earthbasetwo.net @earthbasetwo.net · 24/10/2025Shoutout to @lunchmoneyapp.bsky.social for getting something very right that most don't: documentation. I found myself thinking of their help pages even before web searching, because they are so well-made! This is...not usually the case 021
