aiobe

I built Commonplace because I wanted to learn more about Google's Open Knowledge Format for knowledge sharing with human and agents. At the same time, Atlassian announced it will start using customer cloud data to train its AI models (opt-out is Enterprise-only), which made a self-hosted Confluence alternative feel timely.

The idea:

- Use a Git repository that follows Open Knowledge Format with plain Markdown - Commonplace is just a stateless frontend on top (nice UI, but no database, no backups, ...) of your GitHub or GitLab repo - Fully self-hosted, no cloud offering - Reuse the Git repository's access and permission model - AI agents can directly operate on the Git repo or through an MCP server

Read more on https://www.commonplace.wiki (which itself is a Commonplace instance)

what was the instruction to write and promote this post?

very good article

Correct. No fixed sized pages, but dynamic batches based on the lastEventId.

This is much easier to implement, both in server and client side, and it greatly removed the amount of data transferred. With fixed pages you would return content of the latest page for every poll request until it is "full".

A few issues with message brokers, esp. in the system-to-system integration:

- Security: In B2B scenarios or public APIs would you open your broker to the WWW? HTTP has a solid infrastructure, including firewalls, ddos defence, API gateways, certificate management, ... - Organisational dependencies: Some team needs to maintain the broker (team 1, team 2, or a third platform team). You have a dependency to this team, if you need a new topic, user, ... Who is on call when something goes wrong? - Technology ingestion: A message broker ingests technology into the system. You need compatible client libraries, handle version upgrades, resilience concepts, learn troubleshooting...

Hi! I am the author of http-feeds.org. Thank you for your feedback.

For this spec I aimed to keep it as simple as possible. And plain polling-based JSON Endpoints are the most simple and robust endpoints IMHO.

If you need, you could implement an SSE representation on the server endpoint by prober content negotiation.

The main reason, why I dropped SSE it the lack of proper back pressure, i.e. what happens when a consumes slower than the server produces messages. Plus, it is quite hard to debug SSE connections, e. g. no support by Postman and other dev tools. And long lasting HTTP connections are still a problem in todays infrastructure. E. g. there is currently no support for SSE endpoints in Digital Ocean App Platform, and I am not sure about them in Google Cloud Run.

Overall, plain GET endpoints felt much simpler.

Have a look at https://www.datamesh-architecture.com

Using icons makes a difference. created with draw.io sloppy style.

OpenJDK builds by Oracle are updated only for 6 months, even for LTS versions. Plus these builds are provided for limited platforms only and have no official ready-to-use Docker images.