@grumpy_developer I'm just following the instructions of a rabbit that told me to "use the boost to get through".

Good morning! Need a few extra hours in the day? Pro tip: Send the rest of the universe 99.99% of C and reap the benefits of time dilation!

@mariusor Haha I had never heard of that word until moving to Switzerland. In English calling someone an Otolaryngologist is almost unheard of, we just say "ENT" for ears-nose-throat. So I've only come to know it within the past year when I had to look it up.

@mariusor Very true!

I guess I was more focused the glue keeping the extension compatible between the two paradigms than the substance of the extensions themselves...

I'm sure this is solvable with "yet another layer of indirection" (as is wont of all linked data problems) but don't have the brain power to think on it now.

Another interesting property of extensions is how a scheme like object capabilities -- that lists the permitted URIs to do conduct certain actions on an object -- is in deep tension with the extensibility of the .

New extension Activities cannot *ever* act upon the previous corpus of ocap-protected data. I'm not sure whether that's a feature or not. And the obvious "fix" (spamming a ton of Updates with the new capability) seems wasteful.

Going back to point number 1, there's a chance that extension authors will collide their favorite `@context` alias and then bicker about who was first or more deserving of it.

That's one of the reasons I want to devlop a tool like Adlis, since federating extensions would permit easy discovery of aliases already in use conventionally.

That means the latter apps can hardcode an ActivityStreams Note to be a "Note" string literal and MyPetExtension's (aliased to "mpe") Note to be "mpe:Note".

And since this is inviting re-usable middleware logic between different types, I also highly recommend non-linked-data implementations treat properties as first-class types as well. It's key to building a robust application that can progressively handle more data.

IMO, extensions to should as a convention:
1) Define a conventional alias for the `@context`
2) Actually host a definition of their extension at the IRI value for their alias

That's it.

This preserves the intersection of the linked data world with the world of "just give me JSON". Linked data users can complain about how little of the linked data features are being used. The other side can complain when conventions are broken.

Nobody's happy but everything just works.

@cwebber This is why I am a proponent of the following convention: Never aliasing the ActivityStreams context, always aliasing its extensions.

And @pea
to see them actually working in a client, check littr.me

That page speaks to the API end-points I linked previously strictly through #ActivityPub.

Don't mistake the of the now for the potential it still has locked away under mountains of effort.

@fence Most of his recent stuff progressed to genres I don't understand; I like the atmospheric stuff. His older stuff like Galactic is definitely DnB though.

He also makes some meme-y songs which IMO are pretty good too.

Show more
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!

We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Cafรฉ list of blocked instances. Ash is the admin and is supported by Fuzzface and Brian! as moderators.

Hosting costs are largely covered by our generous supporters on Patreon โ€“ thanks for all the help!