@pukkamustard recently announced a significant change of direction for the #software:openengiadina project, where at least the GeoPub client will be based on XMPP instead of ActivityPub. A similar decision for the CPub generic AP server has not yet been made. Here are some snippets quoted from the announcement as for the reasons to make this change:
The network protocol we have been using is ActivityPub. This seemed to be a perfect fit. We believe that managing knowledge is a social activity and ActivityPub is primarily a protocol for social interactions. Furthermore, ActivityPub can be extended to allow arbitrary RDF content via the JSON-LD serialization.
Unfortunately, we have come to realize that using ActivityPub is considerably harder than we expected:
Using JSON-LD as an RDF serialization is very complicated. It requires the usage of algorithms (e.g. the Expansion Algorithm or the Framing Algorithm) that are incomprehensible and just pure madness. JSON-LD maybe was really just not intended to be an RDF serialization and trying to use it as such is painful.
There are practically no implementations of the ActivityPub Client-to-Server protocol (C2S). This made developing and testing the client and server more time-consuming as we had to develop the protocol in lockstep on client and server. At the end we were still only compatible with our own software.
ActivityPub is not a complete specification and many additional protocols need to be implemented (e.g. WebFinger) in specific ways in order to be compatible with existing servers.
[…]
The fate of CPub - the generic ActivityPub server - is still undecided. We might re-purpose it for an XMPP to ActivityPub bridge or continue development as is.
With the new direction the intent is to retain compatibility and interop with the ActivityPub network:
For openEngiadina we intend to use RDF/XML (an XML serialization of RDF) over XMPP. In fact, we intend to use the ActivityStreams vocabulary serialized as XML over XMPP. This allows, at least in theory, a very clean interoperability with the existing ActivityPub network.
I guess the answer is: No. The last time there was a SocialCG meetup was in May this year. And other than meetings and the intention to set up a #standards:fep process, and open discussions on this forum there hasn’t been much progress afaik. I’ve expressed my concern about this a number of times, but don’t know if that is even broadly shared. Maybe the future of Fediverse is in ad-hoc evolution as is done now (everyone working on own apps, copying from other places, then tweaking until it works), and in theory that can be successful too.
Yeah I have a few apps that I’ve been working on that I’d like to use ActivityPub for, but I’m waiting to see some of these issues get addressed first. I tried implementing ActivityPub server on a couple of projects a year or so ago and just gave up on it. It sounds like the SocialCG could use more sponsors, R&D, and overall support to push more adoption. I have some ideas around how to do that but unrelated to this thread. Perhaps we should start a new thread on that front?
Yes, JSON-LD is also a problem!
I personally would just use a library that translates json-ld to rdf and vice versa. But unfortunately I haven’t found an AP platform yet that creates or understands compatible json-ld.
Many developers seem to understand json-ld as json and not as rdf and that is a big problem. In my opinion most of them don’t speak json-ld!
I’m planning to exchange events with mobilizon S2S, so i would like to play around with it soon. it would be good if a mobilizon expert can help me just in case someone knows one
Btw. i left the project that was implementing the AP C2S App and i’ve no idea if it will get openSourc e and if, when this will happen.
But i started last week to model the reception of activities with https://www.enterpriseintegrationpatterns.com/, i am curious if i get further. I would now have to start another AP implementation and I can not yet say whether I have the strength to do so.
On the topic of JSON / JSON-LD. like both JSON and JSON-LD
I’d prefer it actually if we had JSON with hyperlinks, which might be the best of both worlds
The main issue I see with translating json → rdf is that RDF is a Set, and JSON can have arrays. You can fiddle around in the @context to transform it, but it’s tricky. Set’s can be a challenge to work with. For example try doing simple addition in RDF, it’s hard. Easy in JSON, tho.
A JSON parser could quite easily store JSON as RDF, but without the arrays, you just change the literals to have a base vocab or be relative to the doc (with #)
I think JSON is going to win this battle (some think JSON has already won), so let’s just embrace that, rather than fight it. JSON-LD is fine and has some useful bit, namely you can change stuff into triples (or quads) and do mashups. You can add prefixes to let data be searchable, indexable and matchable, so that’s a nice feature in some use cases
What I’d say is give your objects a unique URI (@id) so they can be easily found, updated etc. even when nested. Give them a @type so that they can be matched, rendered and so on. If you want to use full JSON-LD that’s great too, but I dont think it needs to be strictly enforced especially not for newcomers or existing APIs. Also things of a certain type could become widgets by giving them a @view
Put this data either in html in a script tag, or in a .json file and link from it
I see value in both approaches (using JSON-LD as in the post or going the RDF route). Both requires using the JSON-LD Expansion Algorithm. Given the choice, I would prefer not having to use that algorithm (I invite you to have a in-depth look at the algorithm).
I feel that for openEngiadina XMPP offers functionalities that ActivityPub would have provided without having to use the JSON-LD Expansion Algorithm. That is one of the reasons I believe XMPP is a better fit for openEngiadina.
If you do not need to use the Expansion Algorithm or are fine with relying on existing implementations (like @naturzukunft or @srosset81 for SemApps) then you should not be troubled by my concerns.
@pukkamustard I think i didn’t understand. I didn’t really know xmpp, but i thought it is someting like a protocol, that describes how to send messages over the wire. a little bit comparable with http/smtp ?!
And json-ld is a format for data e.g. messages. For me these would be different things. and if json-ld is the problem, why not use turtle or rdf-xml?
Fredy
Yes, exactly. XMPP is just a protocol for sending messages over the wire. In a similar way that ActivityPub is a HTTP based protocol for sending ActivityStreams activities over the wire.
ActivityPub uses JSON-LD as format. Using RDF/XML or Turtle over ActivityPub is a possibility (the openEngiadina backend CPub used Turtle primarily), but you’re not conforming to the specs anymore.
XMPP uses XML and RDF/XML can be embedded. With this you can use XMPP like ActivityPub, just by using RDF/XML instead of JSON-LD. The advantage is that you are spec conformant and existing software will support what you are doing.
@pukkamustard
Ok, I see activityPub servers as messaging systems and the following 3 things in ActivityPub:
transport protocol (http)
syntactic message (json-ld)
semantic message (e.g. create activity)
If we would distinguish these 3 things, then the semantic message could be transferred via xmpp and still have activitypub compatibility.
Of course I see difficulties in translating different syntactic mappings, but not if we say the messages are RDF instead of json-ld.
Then it is conceivable to offer translators or even bridges as a service. a bridge would also be conceivable for the transport protocol.
It would be nice if we can distinguish these 3 levels at activitypub kombatibilität. then someone could use xmpp and still be compatible.
btw. i’m not sure if there is already an activitypub implementation that really speaks json-ld. But I haven’t looked at the S2S interfaces yet.
Are there xmpp clients that understand rdf/xml? and which semantic messages would you transfer ?
we also need a meta data request, which tells a client what the server supports. e.g. which activities are supported, which object types/attributes are supported, C2S, S2S, …
maybe which transport protocol, syntactic, ?
Agree! It would be very nice to make content (the semantic meaning) be independent of particular serializations and transport protocols. Then it really does not matter so much if content is transported over HTTP, ActivityPub, XMPP, some peer-to-peer network, a USB stick or pigeons.
One important thing is not to make identifiers of content tied to protocols. The solution to that: content-addressing (a la Datashards and ERIS).
I’m not aware of any XMPP clients that understand rdf/xml. And I think I would transfer ActivityStreams activities.
My intentions are not to convince anybody to use XMPP (it has it’s fair share of issues). I just wanted to explain why I believe XMPP is currently a more pragmatic solution for the very specific needs of openEngiadina.
I do want to encourage decoupling content from protocols with ideas like content-addressing.
The first is coupling data to the domain. So in general in Solid we tried to avoid this by having profile items such as users as relative links to the page e.g. #me. Most other systems dont do that, creating a coupling to the domain. I think fediverse and web2.0 have areas to develop in this regard. The good news is that the fix is easy in JSON-LD, you just add “@id” : “#me” to the user object, if anyone wants to go down the slightly more decentralized path
In such a way then objects in a web page become like JSON-LD objects that could be sent over any protocol, reasonably easily. They could be translated to XML too as there’s converters around. So you have a User object, a Message object. I once built a p2p browser to browser chat app using peerjs that did exactly this, and it seemed to work
The other apsect coupling to the protocol, ie by using http vs another URI scheme, such as a content addressible URI scheme. For example, the ni: “naming things with hashes scheme”. Or I guess the did: scheme, tho I’ll point out that it’s not all that decentralized. For example it has a hard dependency on w3.org (an http uri), the very thing it would aim to replace
I’ve settled here on a hybrid solution and that is to have a content addressible timestamped Uri in an http page, that can change over time, and you change the time stamp. So you can start of in one place, and then you record the history of where things go as they move. Anyone that respects your timestamping system will then be invited to update their links, possibly with the help of redirects in the mean time. Doesnt help if someone write down a URL on a napkin, but a move in the right direction
tl;dr clean up data models and they can be sent over any protocol xmpp, http etc & content addressible IMO works better WITH http, rather than, in competition with http
A very concrete problem was that the Framing Algorithm is not yet implemented in the JSON-LD library we are using in CPub (GitHub - rdf-elixir/jsonld-ex: An implementation of JSON-LD for Elixir). This was a blocker for implementing C2S (and eventually S2S) as we could not serialize JSON-LD in the form that ActivityPub implementations expect.
Another problem is that there are very few implementations and it is imho very hard to implement the JSON-LD algorithms so that they are compliant. There are implementations for some popular languages (JavaScript, Python and more), but if you choose a slightly less popular language, you’re out of luck and JSON-LD becomes a huge challenge that you need to face. For openEngiadina we were and are using not so popular languages and this makes JSON-LD a real problem.
One might say: then just use popular languages for which there are JSON-LD implementations. I disagree and prefer not having to use a specific platform/language just to be interoperable.
just in case someone knows one