Shared lexicon schemas for long-form publishing on AT Protocol. Uses typescript to json via prototypey.

Adding a BYLINE field? #10

Open chadkoh.com
Open opened by chadkoh.com

More of a question than an issue.

At Protocols for Publishers ✨ London standard.site was a common topic. One idea that came up was adding a BYLINE field which points to an authour's ATproto account. Currently, posts are attributed to the PDS, which would be the Publisher's atproto account. Yet writers are often not actually part of the org. A BYLINE field is particularly useful to journalists that change publications or freelancers. Such a field also opens up some opportunities for automation and custom feeds.

What do you think? It would be nice if this was at the ATproto layer but maybe we can start it here and it can be adopted by ATP in the future?

+1 to this. Especially considering that a post may be authored by multiple people. I'd generalize it even further honestly to "contributors" which would give us one field for authors, editors, etc... it could take an array of objects with a role property that can be set to a freeform string.

I'd like an author lexicon that represents an author's role, bio, etc. with the publication (even if that's "Contributing writer" or whatever as a freelancer) that also points to the author's did, then an array of authors on the document. @jimjonah.bsky.social's point on contributors is good too.

The trick here is verification. What needs to be on the author's PDS to verify that they did, in fact, author this content? And how can a publishing system handle both records at the moment of publication?

Does it have to be bi-directional? If you are listed as a contributor with your @handle, then it should be searchable and surfacable in feeds right? In your CMS all you would need is to have your contributors with a field for their @handle

Too simple?

I'm more concerned about bad actors misattributing content to people.

Does it have to be bi-directional?

its important that when implementing something like this that we think through the consequences. but also the fact that we should have ways to verify authorship outside of the document itself. just like we can verify documents are real via the metatag validation as specified in the spec.

i am going to start working on something like this soon for @offprint.app so finding a good v1 that may not have every little feature that could be added could be explored and eventually adopted by standard.site.

Sign up or Sign in to add to the discussion.