Post

Hello. I'm interested in this, looking for a little help in understanding the 'content' field. It says it's a union, not entirely sure what that means, an object of any $type? If I were making music documents would I put the actual data in here, or extend the record object with my own fields?

Does this allow publishing content to an existing publication from a different tool? For example, suppose I create a a blog in leaflet and write another tool to post documents to it by updating the pds directly. Is that going to work, or is something going to fail due to "verification?"

That’s going to depend on how the particular host handles incoming records. Different hosts can be more or less locked down in this regard.

You should be able to subscribe, at-mention others blogs, tag your posts, and more. Regardless of which host you choose to use. At the same time, every developer building tools here should be free to experiment and own the formats and metadata they need to ship their products.

The standard.site lexicons define whats necessary for content to move across social boundaries. It doesn't define things like complex themes, or content formats, but since lexicons are extensible, each developer can add those themselves. We think we struck a pretty good balance.

This is still very early, and there's lots to improve on documentation and tooling, but the lexicons are in a good place to start building on. There's a lot more to build, so if you have ideas/needs/complaints/questions, start a conversation on bsky or open an issue on tangled.

This! What I've been trying to explain. For everything data, standard lexicon. Likes, emoji reactions, title, subtitle, categories, tags, authors (for multi-authoring), Canonical URL (for search engine bot use to avoid getting penalised), publish datetime (UTC), last edited datetime (UTC), …

WhiteWind and Groundmist already have publishing lexicons. What gaps are you solving?

Digging into the lexicons for a second: 1. I think "title" is too short. 2. I think themes could/should grow 3. I think a separated spec for colors is unneeded / potentially problematic (would rather store as hex/css colors than rgb) 4. I think you need more lexicons 😉

Thanks! I found the repo yesterday and tried running the tool on my #RaspberryPi, and found that it complains about tool pathing. While I'm pretty certain this is a "my machine" problem, I'm equally certain checking in a generated copy would not hurt (and would be consistent with other projects)

Ooh, this is really exciting! I’ve been tinkering with atproto dev myself recently and have been running into a few data types that would be well-served to have premade - are there plans to expand the scope to stuff beyond the necessities for longform content at the moment?

nitpick on website: can make scrolly stuff less intrusive? i get the animation is fun but it actively *delays* recognition. like i can't scroll and scan. can either reduce duration or make it trigger on load (rather than on each block getting into viewport)

dan coming along and giving some critique on the site 😭 felt like it wasn’t too over the top, but I can tone it down a bit. just gimme some time to play with it a bit, got some stuff to finish first

> ..began as a conversation between developers building long-form platforms on AT. Coordination was the missing piece. I’d love to hear the full story alluded to here. I realize it boils down to ‘so we talked’, but to a lot of techies that’s a major challenge; explicit examples help lower the bar.

That's the goal! Content in the records themselves is totally optional, so they can just point to the WordPress sites published posts

I think the main motivation was that there's a bunch of interconnected stuff that's domain specific, and that a legible namespace for that makes communication and adoption easier. We haven't set any governance stuff in stone yet, so could be potential for a shared body or process there mayhap

We don't aim to replace @lexicon.community but we all had similar implementations and decided it'd be a good time to collab to build the future of publishing. We'll be keeping things specific to publishing long-form and sites also

Lexicon Community doesn’t aim to grab every type of content under its namespace and in fact branded lexicon consortia is a really good outcome. This pattern will repeat - shared knowledge, data type specific needs, and repeat.

Why are URLs primarily referencing / giving examples for https:// URIs? How does one link a publication to a document the atproto way?

The url on the publication record is for the publication home page. Documents point to the publication record’s at-uri via the site property. This creates backlinks. Documents accept https:// or at:// for the site property to support standalone documents and documents belonging to publications.

publication or publisher? "publication" has a singular connotation, associated with the cat of "publishing"

the app.bsky lexicon is pretty much the defacto standard for micro-blogging in the atmosphere. we could've genericized the field name to "microblog" or something like that, but I don't see much benefit.

We also considered having an open ended "links" field, which maybe we could extend to be an array of objects with both "uri" and "rel" properties, and it could capture the bskyPostRef use case in a more extensible way?

That sounds good; I’m thinking of building out static records for my statically produced blog — and I’d fill it with lots of cross-post URIs, like Fediverse links & other sites, as well as Bluesky.

Can you expand on the choice of block based document format over something human readable, and growing in popularity and usage because of #ai... why not Markdown? (i.e. like bsky posts, text+facets)

We don't define a content structure for documents. Platforms are are given the freedom to implement content in the way they see fit. For example, you could just create your own markdown lexicon, and use it in the `content` open union.

We do define a `textContent` (string) property as well, this should contain the text from the content body, used for search and I would imagine AI could easily tap into this if needed.

I understand I can do something different, in general, with lexicon. I'm curious to the choice to this specific block format for a proposed standard, over something like what Bsky did with text+facets My assumption is the choice is largely driven by the underlying pkgs/editors the apps here chose

We aren’t enforcing content type, document content can be block based, markdown, etc. Content is difficult to standardize because there are so many different ways to store it, each with their own benefits and drawbacks. The site.standard.document lexicon supports plaintext, markdown, etc.

probably bc leaflet probably? uses tiptap internally and that’s already really close to tiptap’s internal representation of data

For apps that do not separate publications from user accounts, is it recommended to implement the site.standard.document lexicon alone?

Using just the site.standard.document lexicon alone is totally fine. These documents can be indexed like any other. However, if you wanted a user to show up in an index of publications rather than documents, id suggest including a publication record as well.