Is a Label a thing distinct from Posts in the Architecture?

[bobwyman]

Does the architecture consider a Label to be a thing which is distinctly different from Posts and comments?

It seems to me that a Label can most flexibly and powerfully be modeled simply as a Post that references another -- in essence that it is an annotation of some other Post and just happens to provide content whose data type is easily processed by action functions.

Ideally, a label would have an author and be self-authenticating in just the way that something which annotated some Post with a bunch of comment text would be. (i.e. Just as I can filter posts, I should be able to filter a set of labels to see only those of a particular type that were generated by authors who meet my filtering rules.) Also, it is good that the Architecture says that, as a user, I can create labels. My friends should be able to build action routines based on my labels (e.g. "Stuff Bob likes."). Labeling shouldn't be a special function that is only performed by functions which have some special and privileged access within aggregators.

Ideally, I will be able to comment on Labels created by someone else (e.g. "This label is inaccurate.") as well as comment on that comment. (e.g. "Yes, it actually is accurate, and here is a long treatise on why I think so!") Or, "I label this as a five-star item." Or, I label this as "Like" or "Dislike." Doing this would be facilitated if a label was a "first class" object, just like any other Post -- with the possible constraint that a Label must always carry a reference to some other Post and must have data of a particular type.

Is there any important architectural reason to have Labels be something other than self-authenticating Posts that annotate, or reference, other Posts?

bob wyman

[gerap-mmuk]

In addition to tracing labels back to distinct entities, would you not also wish to allow labels to be tagged or flagged (inaccurate, malicious, accurate, etc.) as Bob points out about, but in a way less likely to lead to a race requirement of being able to label a label's label and further descend down that rabbit hole?

Setting up user-led, verifiable-user mechanism to guard the guards, as it were, by rating the reach/moderation mechanisms sounds like a fairly sensible approach to correct for or at least helpfully highlight moderator overreach/rogue pattern matching/censorship?

It doesn't defend against organised mob collectives attempting to push certain posts, but I don't see that is problem you're trying to or can solve for?

[dholms]

I'm not sure it's necessary to "label a label".

If you don't like a given services labeling, change your service. Some services will likely try to do this algorithmically, some will outsource it to content moderation teams, some will try to crowdsource the labeling. In likelihood, most will do all three.

Most users won't be curating their timeline client-side by pulling labels from hundreds of users. They'll rely on a labeling service to do that.

The labeling service can therefore decide how much weight to give to different users' opinions. A well regarded account with 500k followers will likely have its label carry more weight than 100 labels from bots with 5 followers each.

I've had some early discussions about a reputation/credibility system as well, but have not drilled down into specifics on that.

Lots to think about!

[dholms]

We ended up having this convo in Matrix, but i'll copy over my comment for posterity's sake:

as whyrusleeping said here, the schema system is very flexible. Different apps should be able to define different schemas in different manners. So at the abstract level: Posts, likes, comments, labels, etc are all the same sort of object - a content-addressed document that adheres to a schema published on the schema network. Some schema systems will likely allow the (somewhat) ridiculous chain of "post < comment < like< label < like < comment" that geoah points out. Others will be a bit more restrained in the sort of interactions they allow.

My opinion is we should call things what they are: Likes aren't posts. Labels aren't posts. But likes, posts, and labels are all social media documents that do share many things in common. So let's handle the shared abstraction at one level, but don't introduce complexity at the application layer by pretending that every object is the same "type" of thing. Currently, we split up the documents in a namespace by "posts" & "interactions". As Why said "A like is not a post", & as Aaron Goldman said "It is not yet clear how or even if reactions need special treatment." At the moment we are giving them special treatment, but we've had discussions about removing that divide & treating them all as the same "type" of object

[bobwyman]

Are you assuming that Timestamp is granular enough to identify unique items within a namespace? If so, while that might be a reasonable assumption for a client driven by human interaction, it might not be a good assumption on all systems that might be hosting automated processes like labeling systems.

[dholms]

Yes the TID is granular enough. It's collision resistant & unique to a user's repository. Look up "TID" in the architecture doc for more info. It is based on a user's monotonic system clock + a clock id. It will work for human interaction & also system generated objects.

TIDs are the mutable reference to an object while a CID is the immutable reference.
A contrived example: let's say i have a post "hello world" with CID bafy....asdf & TID 3iwc-gvs-ehpk-2s. Now I update the post to "howdy universe". It's CID may change to bafy...qwer but the TID will remain 3iwc-gvs-ehpk-2s

[dholms]

The important thing about the TID is not "timestamp", but rather "universally unique & monotonically increasing relative to a given agent".

Similar to a time-based UUID as described here: https://www.famkruithof.net/guid-uuid-timebased.html

[bobwyman]

You wrote:

"I think "Reacted to", "Kind", & "Body" all fall into the schema layer."

I suspect that virtually all non-trivial document processing will require access to at least a "Kind" that indicates the document's basic type, purpose, or intent. Given this, it seems that it would make sense to ensure that Kind is as easily accessed as possible as well as accessible without knowledge of anything but a common schema. Certainly, one could require that every schema must identify its Kind in a consistent manner, however, doing that would be semantically equivalent to including Kind in the common schema.

Also, please accept my apologies for not noticing that a TID wasn't a simple timestamp.

[dholms]

Also, please accept my apologies for not noticing that a TID wasn't a simple timestamp.

No worries, there's a lot to take in in the architecture docs 😁

I suspect that virtually all non-trivial document processing will require access to at least a "Kind" that indicates the document's basic type, purpose, or intent.

That's a good point. Objects should be self-describing. When I first read your comment I was thinking of a "Kind" as something like "Comment", "Like", etc. Which I think is more semantic information than we want to put into the protocol data layer. Instead, this would likely take the form of a schema ID which right now we're considering using cryptographic DIDs (did:example:abcd1234....)