Standard.site what's next!
Fields discussed
all these are optional and there will be no breaking changes
Reactions
emojis? enums?
if there's only one reactions, then it would be much easier to build things like recommendations around it
maybe we could have a default "like" and optionally you can add more reactions that don't affect the recommendations
Distinct reactions lex and recommend lex?
It maybe makes sense to start with simple recommends
We can wait to see how a reader implements a lexicon for other reactions before we implement it ourselves
deboost?
seems useful and we don't see any explicit harm
but also who knows, we don't need to include it
We will do a recommend lexicon
up to platforms to render it.
We won't do a more generic reactions lex, and wait to see how others implement
Contributors
It needs to be possible to attribute a post in your pds to someone else (in cases like work for hire)
The governance would be specific to each publication
the publication will decide if they want all posts to be published in their own pds, or authors could keep their posts and publishers pull it
What happens if the publication and the author each keep a copy of the record in their pds
it shouldn't happen, if the publication chooses to mirror, that's a separate copy.
If there's are multiple authors, then there would need to be a group did
If you are attributed by a pub, optionally, there may be a consent lexicon on the author side that proves that the attributor wrote it
this introduces lots of friction in the form of an extra step for the author and another step for the implementation. It needs to be optional
Do we need this, or could it be approximated in links rel
It makes sense to put it top level, lots of docs need it
It makes the content signing easier at the publication level
What does it include
Minimum, a did or string? to attribute to someone else who is not on protocol
Optional metadata like display name
It should be top level
consent mechanisms seem useful and good, we need to explore if thats baked into the standard
a list of dids and roles, with optional display name
Preview Modalities
Different ways to render a post in readers, with for example a video rather than an OG image
a great use of the links array
the links array might be too broad for the reader to know which to display
we should at least have parity with the Open Graph Standard
Links array
relations with NSIDs and a type
A very generic way to achieve a bunch of things that we may want
the content can be a blob while still having backlinks
and we can shove CTA's, and make indexing links easier, link blobs if the docs blog is too big, etc etc etc
Could link also to the OpenGraph data
design q's
open ref union?
or maybe an array of objects that are open ref unions. The links need to be a uri and type at the very least
We're doing it
array of objects: type, uri, data
Contents
should we recommend a format? So that readers can pull them?
this can be solved for now just by putting out better docs
Comments
Formats vary wildly, and will likely blow up the scope of the spec, so we will table this for now, as we consider the best way forward
this will wait for now
Mentions/Quotes
Many apps are already using their own implementation so it would be good to include
however, targeting parts of content that isn't common in type is difficult to do
sounds hard, let's wait
Corrections/Community notes
celine didn't catch the notes for this part, she is sorry, could someone backfill?
sounds hard and other people are doing it, we wait
Generator field
It was useful in twitter when you saw a post and saw the platform that created it, it was great for discovery/virality
For an atmosphere blog, its possible to tell based on the lexicon, but it's not perfect
just a text string? maybe a did?
did makes it friction-ful for blogs that are non-native to the atmosphere.
maybe instead of being in the lexicon, maybe it's part of the validation step?
relatively low risk but we also don't know much about how people will use it, so let's wait on it for now
Payment / Optional CTA
to direct people to where the payments are being triggered
it's a button link that sends the user to a place of the publishers choosing
This does expose a lot of potential problems
this could potentially be done with the Links array
Analytics
Not published in the record, but an XRCP endpoint for publishers to opt in to collect view numbers
Maybe we don't need it? it would be better for the platform should just collect its own analytics
maybe we write a more concrete proposal and shop it around
Tags and Categories
the tags a pretty messy right now, and people use them personally rather than as a global category system
Maybe an internal tag field?
sounds out of scope
Self Labels
NSFW, Content warnings
We specify a top level property like the way bsky and pckt does it
Language
But this is very difficult and seems like no one has a good solution
actually it looks really complicated lol, let's do some research and maybe put out a call for proposals or help?