Implementing a Keyoxide/DOIP API #87

Open
opened 1 year ago by yarmo · 3 comments
yarmo commented 1 year ago
Owner

I will soon be working on an API for headless operation (implemented primarily in the doip library to make sure everyone can use it and adapt it).

Thanks @circlebuilder for the JSON-LD suggestion (#80). I need to dive deeper into the protocol to better understand its benefits. Any JSON-LD experts present?

Regarding functionality, it should primarily do what any Keyoxide client currently does: fetch a key and verify the claims. Any other functions it should have?

I think this is also a good moment to revisit and reconsider the implications of having a "reverse search" API. Not that I have fundamentally changed my stance on this issue, but I am open to hearing good arguments.

I will soon be working on an API for headless operation (implemented primarily in the doip library to make sure everyone can use it and adapt it). Thanks @circlebuilder for the JSON-LD suggestion (#80). I need to dive deeper into the protocol to better understand its benefits. Any JSON-LD experts present? Regarding functionality, it should primarily do what any Keyoxide client currently does: fetch a key and verify the claims. Any other functions it should have? I think this is also a good moment to revisit and reconsider the implications of having a "reverse search" API. Not that I have fundamentally changed my stance on this issue, but I am open to hearing good arguments.
yarmo added the
enhancement
label 1 year ago
yarmo added this to the Feature development project 1 year ago

Thanks @circlebuilder for the JSON-LD suggestion (#80). I need to dive deeper into the protocol to better understand its benefits. Any JSON-LD experts present?

The beauty of JSON-LD is that you can consider it "just JSON". The Fediverse works on exactly that premise, where devs juggle JSON and add a @context property for good measure, because ActivityStreams / ActivityPub is a Linked Data standard (JSON-LD).

The only difference to inventing your own API-specific JSON format is that it is beneficial to search for well-known and used or even standardized vocabulary formats. This way, while you develop your own app independently of others, you keep open many opportunities for others to interoperate with you and vice versa.

Some examples of JSON-LD in the wild. HTML metadata you add for reasons of doing SEO (Google stuff). This is based on https://schema.org which gives you Person and Organization definitions. Wikidata is keeping their stuff as Linked Data. But there are a bunch of other standard ontologies / vocabularies to consider, like vcard, foaf.

If need be you can mix'n match properties from different ontologies to create your desired format (see for instance how Mastodon is doing that).

> Thanks @circlebuilder for the JSON-LD suggestion (#80). I need to dive deeper into the protocol to better understand its benefits. Any JSON-LD experts present? The beauty of JSON-LD is that you can consider it "just JSON". The Fediverse works on exactly that premise, where devs juggle JSON and add a `@context` property for good measure, because ActivityStreams / ActivityPub is a Linked Data standard (JSON-LD). The only difference to inventing your own API-specific JSON format is that it is beneficial to search for well-known and used or even standardized vocabulary formats. This way, while you develop your own app independently of others, you keep open many opportunities for others to interoperate with you and vice versa. Some examples of JSON-LD in the wild. HTML metadata you add for reasons of doing SEO ([Google stuff](https://developers.google.com/search/docs/guides/intro-structured-data)). This is based on https://schema.org which gives you Person and Organization definitions. Wikidata is keeping their stuff as Linked Data. But there are a bunch of other standard ontologies / vocabularies to consider, like [vcard](https://www.w3.org/TR/vcard-rdf/), [foaf](http://xmlns.com/foaf/spec/). If need be you can mix'n match properties from different ontologies to create your desired format (see for instance [how Mastodon is doing that](https://docs.joinmastodon.org/spec/activitypub/#namespaces)).

This issue is blocking adding Keyoxide as an "identity provider" in Mastodon: https://github.com/tootsuite/mastodon/issues/13670#issuecomment-832623793

If we had an API that can be queried from Mastodon then Keyoxide could be a first-class citizen (just like Keybase now is).

This issue is blocking adding Keyoxide as an "identity provider" in Mastodon: https://github.com/tootsuite/mastodon/issues/13670#issuecomment-832623793 If we had an API that can be queried from Mastodon then Keyoxide could be a first-class citizen (just like Keybase now is).
Poster
Owner

Good point, @wiktor! We need that API. Is there a way to collaboratively design it? I'd rather not "go with my instinct" to then discover I looked over all the important stuff 🤦

Good point, @wiktor! We need that API. Is there a way to collaboratively design it? I'd rather not "go with my instinct" to then discover I looked over all the important stuff 🤦
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.