Thanks for answering fast, I’ve (hopefully) corrected the links in the original post.
About context, the truth is that I dont really understand how it works
What is important: We speak about @context and not context.
The first is a useful underlying property from the JSON-LD specification.
The second is explained in “ActivityVocabulary”;
It is a native ActivityStreams property meant to group things.
anyway
about @context
Without using it, Sir Tim Berners Lee would award Lemmy with 3 of 5 stars … 
When you use it, you can earn the 4th star.
The spec. tries to explains @context – recommending to read it in the order:
- Section Extensibility in the underlying spec. for “ActivityVocabulary”: Activity Streams 2.0
- Section Context in the very underlying spec. JSON-LD 1.1
Let me try:
It is to “use URIs to denote things, so that people can point at your stuff”
See the benefits
In short:
Any property in the JSON document is not a word but an URI.
We do not want to repeat things, so in the @context field we can
- define a Base URI for unprefixed properties (it is
https://www.w3.org/ns/activitystreams#) unless specified specifically
- define prefixes which are like “shortcuts” and denoted by
:
- define a property and its behaviour specifically
Then any property becomes a unique URI which can also point to both, a machine and human readable definition for the property. With multilanguage labels as bonus (like in wikidata or redaktor).
Now for example
{ "type": ["adidas:Offer"] } or { "type": ["puma:Offer"] }
can have different specified meanings (and if you see the company history probably have).
Which brings me to
Mastodon’s toot:featured field contains a collection of all stickied objects
You are right, sorry. Let us think it federated.
Both make sense and so you should use your own namespace.
Trying to highlight the differences.
On the one hand when an application shows the Outbox of an Actor (e.g. under the Profile), the mastodon approach makes sense cause you do not want to parse it until the end to know all sticky.
On the other hand when you treat Objects of different Actors, like when viewing your Inbox, “lemmy stickied” is fine to just show e.g. an Icon or “sticky”-label …
Please also note that id and context are aliases itself, specified by the “ActivityStreams 2.0 Terms”.
But the @context itself is independent. Since yours is consistent I could cache it for generator = Lemmy (recommending to use generator property).
But in the @context itself it must still be @id and @type (note the @ !)
The schema namespace is “http://schema.org/” (no “#”, it exactly replaces the “sc:”).
And if you want to alias things from “as”, you need to specify what “as” is.
tl;dr
proposing:
{
"@context": [
"https://www.w3.org/ns/activitystreams#",
"https://w3id.org/security/v1",
{
"as": "https://www.w3.org/ns/activitystreams#",
"lm": "https://join-lemmy.org#",
"pt": "https://joinpeertube.org/ns#",
"sc": "http://schema.org#",
"comments_enabled": {
"@type": "sc:Boolean",
"@id": "pt:commentsEnabled"
},
"matrixUserId": {
"@type": "@id",
"@id": "as:alsoKnownAs"
},
"moderators": {
"@type": "@id",
"@id": "lm:moderators"
},
"stickied": {
"@type": "sc:Boolean",
"@id": "lm:stickied"
}
}
]
}
Basically to avoid confusion for people not using JSON-LD/@context, I would rename ‘comments_enabled’ to ‘commentsEnabled’ as in peertube.
And: regarding @type, normally AP uses "xsd": "http://www.w3.org/2001/XMLSchema#" to describe functional datatypes like xsd:boolean.
@nutomic et al.
please do also attend the monthly meetings each 2nd TUE a month. We spoke and speak about all the @context and context things …
