Website
-
The contents of the website have been outsourced to a separate project.
-
I have put a lot of effort into documenting the concepts and background, which is really a very difficult task. I got very positive feedback, but also not so great feedback from people who are not so technically savvy. Too bad I would have hoped to pick up these people better.
-
rdf-pub is a project made for technicians. It is intended to facilitate the development of applications in the fediverse by enabling client to server interactions. This means that not every application developer has to deal with all server-to-server interactions. So there’s not much to say for people who aren’t that interested in technology.
-
-
I added my vision today (25.1.25). Hopefully even non-technicians can do something with it.
-
The news, the links to the architecture documentation and the generated technical reports are now also on the new website.
Tesing, Federation
-
I have now been successful with my HTTP signature. There is initial communication between friendica, mastodon and rdf-pub. However, the federation is not a simple process. I am now in the process of developing the following process and testing it with friendica and mastodon. I also have to get to grips with UI development again.
-
by the way, i finally managed to integrate a disclaimer into the keycloak, so that nothing stands in the way of activating the demo app. i now have to test again technically test how the forwarding of the public domain to my developer instance works. I am confident that others will soon be able to use the demo app.
Refactroing
-
In the rdf-pub-app module, I have emphasized the technicality more clearly by introducing UseCase classes.
-
In many use cases, I now work with the command-query-responsibility-segregation pattern. In other words, the separation of query commands and change commands. Structures are used that can later be used as events.
-
The rdf-pub-store module has also been tidied up a bit and the documentation has been completed. Unfortunately, most of the modules are still waiting for some time and love to clean up and document them.
-
Previously there was one database per actor. Since there are applications in fediverse that send their activities without making them retrievable, I was forced to introduce caches. So now there is at least for the PendingFollowing activities an independent cache that is independent of the actor database and stores external activities.