I’m still working on the PeerTube-Browser project and wanted to share a small update on what has been happening lately.
Since the previous post I made several changes that are probably not very visible from the user side, but they are quite important from an architectural perspective.
Engine and Client separation
I split the system into two separate components: Engine and Client.
The Engine is essentially a service that crawls data from PeerTube instances. It collects and indexes that data and exposes it through an open REST API.
The Client then communicates with the Engine through this API to fetch the data and display it to the user.
The idea behind this separation is to make the Engine something that can run more or less autonomously. In the long term it should be a service that you can just start and let it run without much moderation or manual intervention. At most it might require occasional moderation of things like instances or channels.
So the Engine’s responsibility is simple:
collect data, index it, and provide access to it.
The Client’s responsibility is different:
take that data and present it to users in a useful way.
Because the Engine exposes a public API, it also opens the possibility for other integrations. In theory anyone could build their own front-end, client, or integration using the data the Engine provides. For example, someone could create a page on a PeerTube instance that shows videos only from that instance’s federation, or build alternative interfaces or tools on top of the same dataset.
At the moment the API is still undocumented and evolving. The Client already communicates with the Engine through it, and technically anyone can query the Engine at:
engine.peertube-browser.com
There are a few endpoints available that return data, although they are still experimental and will likely change as the system develops. The plan is to gradually expand and stabilize this API so it becomes more flexible and useful for building additional tools, integrations, or alternative frontends.
Current work
Right now most of my work is focused on the development workflow, particularly how to work with AI agents inside the project.
As the project has grown, I started running into some limitations and practical problems when using agents for development. Because of that, I’m currently designing a workflow that helps structure this process better.
Part of this work also involves figuring out how to track and present development progress publicly on GitHub. I want to create a workflow that allows me to keep transparent records of development activity while also automating some repetitive parts of the process.
The goal is to optimize how I interact with AI agents during development and make it easier to show progress publicly as new features are implemented.
What’s next
I already have a rough plan for the functionality that should eventually be implemented. For now I’ll keep moving forward step by step following that plan.
Feedback from the previous post was very helpful, and I’m taking those comments and suggestions into account. If you have ideas, thoughts, or criticism — feel free to share them.
Support
At the moment the project is funded entirely by me. I’m building it not for personal use, but because I think it can be useful for others and because I genuinely enjoy working on it.
Also, to be honest, working on something meaningful helps keep my mind occupied during the war here in Ukraine.
If you find the project interesting or useful, and you want to support its development, I would really appreciate it. Seeing that people care about the project and use it is a huge motivation to continue working on it.
You can support the project in two ways:
- Patreon — for recurring support
- Donatello — a Ukrainian service that allows one-time donations directly to my Ukrainian bank account
Project's repo:
https://github.com/denikryt/PeerTube-browser
Any support, feedback, or ideas are very welcome.
Thanks for reading.
