openEngiadina: From ActivityPub to XMPP

[naturzukunft]

the challenge will not only be to have json-ld parsers/generators in different languages. the bigger challenge will probably be to make them compatible
I am very, very curious. I will use existing json-ld libs in my implementation and will report what that leads to. Since the day before yesterday i’m hacking again, let’s see how long i can keep it up. but i’m working inside with rdf4j as abstraction and transport turtle. json-ld will “only” become an in/out adapter/translator in my case.

Once I’m a little further along, I’m happy to test json-ld compatibility with others. i’m starting with C2S though.

[melvincarvalho]

I worked with JSON-LD parsers for a long time

But the large footprint and buggy implementations have lead me to favour a different approach

And that is to use general native JSON parsers, and extract the relevant LD from the payload

[Sebastian]

It is a very nice, encouraging article.
One more important point is

“And why has everything become an array?”

Cause it does not help anybody if software expects it not to be an array when ActivityPub clearly says, it can be an array.

The Fediverse needs JSON-LD alone for not loosing content.
Have a look at e.g. Federation - Mobilizon – you would loose all the schema.org properties when you just use the JSON payload.
If you don’t use JSON-LD, your software will not know where the event is and all users are lost. This is one of 1000 examples.

---

about

“There are practically no implementations of the ActivityPub Client-to-Server protocol (C2S)”

I am leading a team at a large publishing house writing a server and a client and I am using every free minute to write my Open Source client, see Commits · redaktor/widgets-preview · GitHub

And so the above sentence is just frustrating and disencouraging to read that there are no implementations (apart from:)

• pleroma,
• and-status
• smithereen (see sloph to smithereen demo)
• independent clients and more

[pukkamustard]

@Sebastian

And so the above sentence is just frustrating and disencouraging to read that there are no implementations (apart from:)

• pleroma,
• and-status
• smithereen (see sloph to smithereen demo)
• independent clients and more

Thank you for pointing out the existing C2S implementations. I changed the wording in the post to “There are not many implementations of the ActivityPub Client-to-Server protocol (C2S).” and linked to your post.

It was not my intention to frustrate or discourage. Sorry that you felt so.

[Sebastian]

Well, it is one choice less for our users now … And you were the only ActivityPub project who made it through that strange NGI0 thing, I think.

Wondering how other ActivityPub Elixir devs will handle it, e.g. https://lemmy.ml/post/95684 …

Anyway: What should we do with the Talk then?
It is false information now…

[naturzukunft]

@Sebastian

It is false information now…

Absolutely not ! json-ld is still linked data. Even it’s awful
My implementation will understand json-ld and it will also generate json-ld. I’m just afraid that very few people can interpret my json-ld. I currently working on an docker image.
Features now:

• Receiving a create activity
• read activities/Objects by their subject
• no authenticatiopn yet
• no actor profile yet.
• supports json-ld, turtle and many other rdf syntax.

[naturzukunft]

maybe we should think about a webservice that translates json-ld to turtle and vice versa.
I have one processor each for (in/out) that does this translation for me

• ProcessorInMsgTranslatorToTurtle
• ProcessorOutMsgTranslator
• MsgTranslatorToTurtle

[Sebastian]

What I meant is that the info with ActivityPub in the video is not up to date and viewers could be thankful for an update (maybe via comment) …

that translates json-ld to turtle

Yes maybe – will look what turtle is is exactly.
I am using the “reference implementation” of the JSON-lD tools for node.js …

GitHub - digitalbazaar/jsonld.js: A JSON-LD Processor and API implementation...

Manu Sporny was also engaged at the Conference and it works nicely for me.

[naturzukunft]

@Sebastian

I am using the “reference implementation” of the JSON-lD tools for node.js …

Sound’s great, so your client can be the first test client for my C2S Server

[Sebastian]

Well, just some coming to my mind …
There is much more !

This post is a wiki, add yours:

Implementations of the ActivityPub Client-to-Server protocol (C2S)

• pleroma incl. 12 clients
• mammoth
• socialhome
• μblog.pub
• aardwolf
• pubgate
• and-status (android)

Server

• Go-fed
• Epicyon
• SemApps
• Fedbox

Also leaving this here

The ActivityPub Panel

One thing that I think is key but maybe not obvious from the spec: The AP Client-to-Server API isn’t just aimed at mobile or desktop apps. That’s the obvious and straightforward use case, but not the only one. What the C2S API gives you is delegation. It lets some other agent - which might be a mobile app, or might be a web app - act on your behalf. And, importantly, it gives those agents effectively equal power to the server itself has. In the extreme, you could have a server which has no UI…

Implementing ActivityPub Client-to-Server

ActivityPub Client-to-Server (AP C2S) API compared to other APIs allows to have more flexibility and control of the activities/objects, plus proper multi-instance abilities (origin URIs instead of IDs local to the instance). Pleroma Backend has the ground layer of AP C2S and has been almost not progressing from it for a while. AndStatus is a standalone client which does AP C2S among other APIs. And so far that’s what I’m aware of. I think we should see how to effectively kickstart this API i…

PS: Not sure about https://bonfirenetworks.org but Mayel is also doing Elixir, see GitHub - bonfire-networks/activity_pub: Modular ActivityPub library in Elixir

[aschrijver]

Some more description by @pukkamustard on rationale of using XMPP as discussed on Matrix:

Do you think I should go for XMPP? What would be the pros and cons?

I think you should go for XMPP. There are three main advantages I see:

1. Everything you need to get it working is well specified. You need to read a RFC and a couple of XEPs. Unfortunately ActivityPub seems to be underspecified and getting a working/federating implementation is non-trivial.
2. There are working, well-tested and generic XMPP servers that you can just use. Generic in the sense that XMPP servers do not care what kind of content you transport over them. This is not the case for ActivityPub. I am not aware of any ActivityPub server that allows arbirtary types of content to be transported. This was something we were trying to do with CPub. With XMPP we just use ejabberd or prosody (both work perfectly fine).
3. With XMPP you’re not bound to Web technologies. XMPP main transport is TCP, but it works over WebSocket (what we are using in GeoPub) and other things such as radio links (XEP-0361: Zero Handshake Server to Server Protocol). ActivityPub is a Web first stack. If you create a non-web client you still need a lot of web libraries.

Cons:

• You need to read some XEPs and other documents that look scary.
• You need to deal with XML. But IMHO that’s better than having to deal with JSON-LD.

Can we easily bridge XMPP with ActivityPub?

Libervia project is working on this (NLnet; XMPP-ActivityPub gateway).

GeoPub uses ActivityStreams over XMPP. Which should make a bridge very easy (ActivityStreams over XMPP — inqlab)

Later on @pukkamustard mentions:

Of course there are a couple of generic ActivityPub servers in development. Among them rdf-pub by @naturzukunft (linkedopenactors / rdf-pub · GitLab)

Also worth mentioning ActivityPods (GitHub - assemblee-virtuelle/activitypods: ActivityPub + Solid PODS = ❤️) and Bonfire (https://bonfirenetworks.org/)

(There’s also https://semapps.org)

[Sebastian]

Considering that many people, who are doing generic servers, looked for help –
and considering all the meetings, I disagree.
Also, I started GitHub - redaktor/server which just went the closed-source-way for G+J cause we did not get funding at nlnet …
It seems to be a vicious circle but maybe we should actively collect the efforts.

Apart from go-fed, python ap, epicyon, bonfire, semapps … there is also a Rust start now:

RATP : a generic ActivityPub server