@heluecht @jaywink What's the thinking RE:

I had designed go-fed to always generate JSON-LD contexts where non-AxtivityPub vocabularies are aliased so that there's no property name and no type name collisions between different things.

I'd like to standardize on that so we can be future proof for further RDF compatibility.

Don't know if @Gargron and @nightpool and @kaniini would be interested as well.

@heluecht @jaywink @Gargron @nightpool @kaniini Alternatively, the cats already out of the bag, and since no one really parses JSON-LD at runtime, we'll just standardize on what's already out there, I'll change go-fed, and we'll live with the possibility of vocab collisions. Which avoids painful migrations.

Show thread

@heluecht @jaywink (this isn't meant to be accusatory, I genuinely want to know so I know how to proceed together 😀)

Show thread
@cj @Gargron @jaywink @kaniini @nightpool Friendica is indeed using a JSON-LD library to compact the JSON. So an invalid JSON-LD will lead to parsing problems.

@cj I'm not sure I understand the question. The PR linked doesn't look like valid JSON-LD at all. Valid JSON-LD would look something like:

"@context": [
"sec": ""
"sec:publicKey": {
"id": "http://localhost:8080/api/v1/ap/actor/lukas#publicKey",
"sec:owner": "http://localhost:8080/api/v1/ap/actor/lukas",
"sec:publicKeyPem": "-----BEGIN PUBLIC KEY...",
"type": "sec:PublicKey"

@nightpool Thanks for pointing this out -- go-fed is definitely not propagating the default alias at serialization time, so that's a bug.

However my original question still stands --- if go-fed does alias the security context to "widsv" or anything else, can Mastodon et. al. (+cc @heluecht @jaywink ) handle deserializing that, or do they do non JSONLD deserializing and expect "publicKey" to never have a prefix?

@nightpool @heluecht @jaywink I basically either need to fix the bug or tell the code generator the "community standard" of context aliasing.

@cj @jaywink @nightpool when it is a valid JSON-LD, Friendica will be able to parse it, with out without prefix.

We are doing the compacting here:…

We are then reading the key here:…

@cj @nightpool @Heluecht Socialhome will be able to parse it in the future, currently no. I'll be adding a JSON-LD library in between as soon as I get the basic functionality out.

I don't know JSON-LD well enough to say whether the current is a bug or not? If the security context is not an object, does the property require a prefix to be valid JSON-LD?

Please guys try to always reply to all btw, difficult to follow otherwise :P

@jaywink @cj @heluecht the way mastodon currently serializes it is also valid JSON-LD, although there ARE some subtle differences between the two. As I understand it, the array form is including the entire context while the object form is only referencing the namespace.

mastodon would not be able to process "sec:publicKey" currently, but I would prefer you federate the extension the way you prefer to and then open an issue to have us make our code compatible rather then the other way around.

@cj @Heluecht @jaywink @Gargron @nightpool @kaniini

it feels like everyone looked at mastodon as a reference implementation

Sign in to participate in the conversation
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!