So is this now the cleanest way to add #RDF to nostr events?
Cc nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24
The Mostr bridge now has a new way to tag ActivityPub content on Nostr. This has been standardized in NIP-48! π https://github.com/nostr-protocol/nips/pull/693
Previously Mostr events used the ambiguous and proprietary "mostr" tag to indicate people and posts from ActivityPub, eg:
["mostr", "https://gleasonator.com/objects/9f524868-c1a0-4ee7-ad51-aaa23d68b526"]
Now those "mostr" tags are gone, and the same ting would instead be expressed like this:
["proxy", "https://gleasonator.com/objects/9f524868-c1a0-4ee7-ad51-aaa23d68b526", "activitypub"]
Proxy tags can be used to locate the original content on the web. Not just for ActivityPub, but also for RSS, Matrix, Bluesky, and whatever else we decide to bridge.
Clients can use this to indicate messages from other protocols, and may choose to include a link to the source content. It could even be used to deduplicate content between bridges and merge threads.
So is this now the cleanest way to add #RDF to nostr events?
Cc nostr:npub1melv683fw6n2mvhl5h6dhqd8mqfv3wmxnz4qph83ua4dk4006ezsrt5c24
ActivityPub isnt even RDF. Proxy tags allow you to import content to nostr from other networks e.g.
- mastodon
- rss
- bluesky
- matrix
- telegram
Thanks! I thought for a moment that we could add "jsonld" for pointing to a document containing that data. But that seems not to be the intention of the nip.
curl -LH'Accept: application/ld+json' https://w3c.social/@csarven
will give you activity pub with a context that can be interpreted as a form of json-ld I am told.
But ask @csarven@w3c.social
The #ActivityStreams core standard
https://www.w3.org/TR/activitystreams-core/#jsonld
says
βThe serialized #JSON form of an Activity Streams 2.0 document must be consistent with what would be produced by the standard #JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm using, at least, the normative JSON-LD @context definition provided here.β
So that means that Activity Streams should have a good extensionality story, and so adding tags with semantic content should not be too difficult.
Re tags. There was a company called Faviki that did a very good job of linking #tags to Wikipedia, via DBpedia, perhaps. This allowed people to come to agreements over tags in a communal way, and it allowed one to search for similar tags or implied tags. (also it could help with translation between tags)
I wrote about Faviki somewhere on blogs.sun.com, but I did not find it. Here is one thing I wrote on the subject:
Sorry I meant to link to the web archive version of the blogs.sun.com post https://web.archive.org/web/20091004034050/http://blogs.sun.com/bblfish/entry/search_tagging_and_wikis