Agape-Apps: Building Baruch Together

[Jonathan1]

Dear brothers and sisters,

 

I would like to start a new development thread here on JWtalk for Agape-Apps Development.

 

My name is Jonathan, 60 years old, I was born and raised in the truth, and I live in the Netherlands (Utrecht area). I have been working professionally in software development for many years. I have served in the congregation in different capacities, and over time I noticed how much administrative work is involved in planning and coordination.

 

I genuinely appreciate what has already been built in this field over the years. Many brothers have invested an enormous amount of time, skill, and dedication into developing tools that have helped congregations worldwide. That work deserves respect. At the same time, the technological landscape is changing rapidly. Supporting modern mobile devices, multiple operating systems, and continuous online synchronization introduces new challenges — especially in areas such as:

• device security

• authentication methods

• encrypted communication

• version compatibility

• long-term maintenance

• and secure update distribution

 

What worked well ten years ago in a primarily desktop-based environment becomes more complex when you expand to:

• iOS and Android devices

• cross-platform synchronization

• offline-first mobile apps

• automatic background updates

• and varying security models per operating system

 

Mobile ecosystems evolve constantly. Security policies change. Operating systems introduce new restrictions and new requirements. App stores enforce different compliance rules. That doesn’t make older systems “wrong” — it simply means the environment has changed. Part of what motivates this development is exploring how to design an architecture that is sustainable and secure in this new multi-device reality, while still remaining simple for congregation use.

 

For the development of the app, I am using a “build-in-public” approach.

This means I will share weekly YouTube development updates — both on social media and here on the forum — where I transparently explain:

• progress

• design decisions

• functional architecture

• and technical implementation

Because development is shared openly, feedback can be incorporated step by step instead of waiting until everything is finished. That way, the application can grow in the right direction from the very beginning — shaped by real-world use, practical needs, and the collective experience of the community.

 

At the moment, I am still a one-man army. But I sincerely hope this can become something collaborative — where brothers and sisters contribute ideas, insights, testing feedback, and perhaps even technical input.

 

It is certainly an exciting time. I look forward to constructive discussion and thoughtful feedback.

 

Agape,
Jonathan

 

Edited 7 hours ago by Jonathan1

[Dages]

You have a github?

[Jonathan1]

1 hour ago, Dages said:

You have a github?

Not publicly at this stage.

I’m currently focusing on solidifying the core architecture before opening up the code.

Since the architecture is still being shaped, I prefer to keep development centralized for now to avoid fragmentation early on.

My goal with the “build in public” approach is transparency and iterative feedback — not yet community-driven code contributions.

Once the technical foundation is mature, I will reassess how to structure broader collaboration.

[Eryk]

If I may make a suggestion: Please keep your messages as concise as possible. I, for one, have no time (nor desire) to give youtube my clicks. Others, of course, won't mind that approach, so I'm not telling you not to do that. Just that, personally, I would like to know what your app(s) do(es) and how in as brief a manner as possible, so as to ask the pertinent questions and get the necessary details 

[Jonathan1]

Baruch Architecture – Privacy by Design

When building Baruch, I made one fundamental architectural decision:

Personal data should not live in the cloud.

The system is therefore built around strict separation of concerns.

1. Local First

Each device (elder, ministerial servant, publisher):

• Stores personal data locally

• Maintains its own secure database

• Can operate fully offline

Names, addresses and contact details never leave the trusted device.

2. Event-Based Synchronisation

Baruch uses an event-driven model instead of direct database synchronization.

When a change is made:

1. The change is written to the local database

2. A domain event is created

3. The event is stored in a local Outbox Event Store

4. The Outbox pushes anonymous events to the server

5. Other devices replay the events locally

Only anonymous planning data is synchronized.

No personal identifiers are transmitted.

3. Cloud = Stateless Event Relay

The server:

• Does not store personal data

• Does not hold re-identification keys

• Only distributes event streams

Even in a hypothetical breach, no personal data can be exposed.

4. Security Model

• TLS encrypted communication

• Principle of Least Privilege

• No centralized personal data

• Event versioning for safe upgrades

• Full audit trail without storing PII

Why this matters

Recent security reports show that centralized cloud storage of personal data increases breach impact significantly.

Baruch reduces the blast radius by design.

If the cloud is compromised, there is no personal data to leak.

That is not an added feature. It is the foundation.

[Brandon]

Is it a platform for congregations? I’m a bit unclear