Caveat: the "description" property is probably wrong; it should match the definition of the ActivityPub(!) "source" property which is currently not in go-fed.
`Id` is causing the linters to complain when implementing the db interface.
from the go project https://github.com/golang/go/wiki/CodeReviewComments#initialisms
> This rule also applies to "ID" when it is short for "identifier" (which is pretty much all cases when it's not the "id" as in "ego", "superego"), so write "appID" instead of "appId".
As I was ~~wholesale copying~~ using the `database` interface definition
as a reference while creating my Federating implementation I noticed
some instances of a variable being named `inboxIRI` in an outbox method.
There is still a context-order-dependent stability issue in the tests
impacting the PublicKey test, which must be fixed.
The fix for the PropertyValue test involved wrapping an
ActivityStreamsObject directly (instead of a Type). Note that only
serialization is supported in this case.
This was a fucking nightmare, as expected. All because the PublicKey
type is not really a derivation of the ActivityStreams "Object", which I
had been hackily relying on for things to inherit the JSONLD "id" and
"type" properties.
This breaks the "id" and "type" JSONLD properties into first-class
properties known within the tool, which for now is a patchy job of duct
tape to cover the leaks.
If someone wants "PublicKey" to have more default supported properties,
I will kindly ask them to fork a code generation that suits them. This
took way too much effort to treat PublicKey like a grab bag.
This isn't the fix for, but is on the road to fixing, the known bug
about aggressive deserialization of "PublicKey" into other types. In
fact, this is on the way to *correctly* fix it without a horrible patch
in the generated code (imagine being hacky in []jen.Code{...}, that's
too much poo to put into the meta code).
The things I do to support incomplete ontologies and major Federation
players that, for whatever reason on this god-forsaken planet, decided
to adopt the ontology and type everything except "PublicKey" (I don't
count "endpoints" because that is a pile of steaming poo for another
different reason in addition to this one, and is completely optional).
No longer create "default aliases" for JSON-LD vocabularies. This would
break compatibility since the way JSON-LD propagates aliases is pushed
downwards, and not propagated upwards. Since a lot of implementations
don't actually care about JSON-LD, do a lot of hacking to make sure that
others that expect hardcoded contexts and the like will still be able to
handle our output.
Still need to hook together the "well known alias" so it can generate
contexts that match the community, but that will be for things like the
custom mastodon and litepub extensions.
I don't want to ever have to work with JSON-LD in a static language ever
ever again. This is shit code.
Cory Slep
Ben Lubar
Andreas Schärtl
Sevki
Dan Conley
Walfie
Lukas Matt