First time I’ve heard of Gush!, an activitypub based platform for sharing topical interests for video games.
General Discussion
3
Posts
3
Posters
36
Views
-
First time I’ve heard of Gush!, an activitypub based platform for sharing topical interests for video games. Other media types are being considered for development as well.
-
First time I’ve heard of Gush!, an activitypub based platform for sharing topical interests for video games. Other media types are being considered for development as well.
box464@mastodon.social very cool, is the creator on fedi? I'm assuming so...
-
Gli ultimi otto messaggi ricevuti dalla Federazione
-
We hope this will enable the fediverse to become a safer space for activists and communities to organise, coordinate, and collaborate meaningfully. By making secure, user-friendly messaging a core part of the fediverse, we can help lay the groundwork for decentralised networks where people can go beyond talking in the mythical ‘global town square’ and actually organise and accomplish things together.
-
RE: https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/
Big news for the #Fediverse! End-to-end encryption is coming to #ActivityPub.
@swf with support from @sovtechfund is coordinating two interoperable implementations.
Bonfire is proud to be one of these first two projects, alongside #Emissary by @benpate
We think #E2EE should simply be the default for any private communications, and we’re especially thrilled to bring private, trusted collaboration to the fediverse.
-
@eyeinthesky@mastodon.social Thanks. In your description, does "primary resource" refer to https://enigmatick.social/user/jdt#main-key or https://enigmatick.social/user/jdt?
That matters since the latter is not known as accurate until the resolution is complete.
Practically speaking, it's clear that I can retrieve the Actor resource using the fragment ID (https://enigmatick.social/user/jdt#main-key) and then retrieve the owner field from the publicKey field of that object to arrive at the Actor ID. Although since the leap to look in the publicKey field doesn't seem like it's specified by LD-JSON, I suppose just pulling the id from the returned Actor object directly might be as valid.
-
@mariusor @jdt For keys, the algorithm to resolve the key's actor/owner is what @silverpill described (fragmented or otherwise). To dereference RDF fragments in general, you must retrieve the primary resource and search for a subject with the full IRI as the id (including fragment). The fragment does not generally reference a property (RDF predicate) in the primary resource, but it could in specific cases.
-
@jdt the way I interpret it for JSON-LD documents is that the fragment is the actual name of the property inside the document that the IRI refers to. So in the case of a public key would be https://example.com/jdoe#publicKey (instead of jdoe#main)
I haven't seen anything in the documentation to give a more explicit, or different, mechanism.
-
@mariusor@metalhead.club That's great context; thanks!
-
@silverpill@mitra.social That makes sense. I guess I was getting a little bit spun around by the idea that the keyId is not the Actor id and thinking too hard about it.
-
@jdt the fragment in a JSON-LD document IRI has a semantic meaning that goes back to RDF: https://www.w3.org/TR/rdf11-concepts/#section-fragID
> a secondary resource that is usually a part of, view of, defined in, or described in the primary resource, and the precise semantics depend on the set of representations that might result from a retrieval action on the primary resource.
