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 yesterday at 09:38 AM 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

[Jonathan1]

2 minutes ago, Brandon said:

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

 

Baruch is designed as a congregation planning system (comparable to NWS) — specifically to support appointed brothers in organizing schedules such as Christian Life and Ministry Meetings, Public Talks, and other congregation responsibilities.

However, it is not a traditional centralized cloud platform, and it does not use a congregation-sharing system for synchronization. Each device keeps its own data locally, and only anonymous planning events are synchronized between authorized devices.

 

Each congregation works within its own environment. Personal data remains local on trusted devices, and only anonymous planning events are synchronized between authorized devices.

So you can think of it as:

- A congregation-focused planning system
- with privacy-by-design architecture
- rather than a central cloud-based platform.

I

hope that clarifies it — happy to explain further if helpful.

[Brandon]

3 hours ago, Jonathan1 said:

happy to explain further if helpful

Are you still in the planning phase? Or looking for beta testers?

[Jonathan1]

1 hour ago, Brandon said:

Are you still in the planning phase? Or looking for beta testers?

Thank you for asking.

 

The core architecture is already implemented, and the application is actively under development. So it’s no longer just a planning phase — the foundation is in place.

 

My intention is to release Baruch in phases rather than waiting until everything is “finished.” Each released set of functionality can then be evaluated and tested in a real-world setting.

 

This allows for an iterative development process:

• Early features can be reviewed and validated
• Feedback can be incorporated immediately
• Adjustments can be made before the system grows too large
• Regional or practical differences can be addressed step by step

By working in phases, we avoid building something in isolation that may not fully reflect real congregation needs. Instead, the application can grow in a controlled and thoughtful way, shaped by practical experience.

Another advantage is stability. Each phase can be hardened and refined before moving to the next, reducing the risk of large structural changes later.

 

I would genuinely appreciate your participation in testing when the first stable phase is available. Having thoughtful input from brothers with practical experience is extremely valuable, especially in ensuring that the workflows feel natural and realistic.

[Eryk]

1. Please clear something up: you say it's similar to NWS, which is used to schedule; is there a complimentary NWP part for every publisher?
2. Also, you say the data itself is not synchronized, but what if, for example, the secretary adds/updates a record, how is that passed to the others?
3. I believe the server queues tasks and redistributes them in order to the other devices. What if one device send a modification to the server but then goes offline and other events happen. Can the app continue to function locally (continue modifying, etc.) without being jammed up?

[foghorn]

Bro. Jonathan - glad you took the suggestion to establish a separate topic for your project. Looks like there is quite a bit of interest already.

[Jonathan1]

3 hours ago, Eryk said:

1. Please clear something up: you say it's similar to NWS, which is used to schedule; is there a complimentary NWP part for every publisher?
2. Also, you say the data itself is not synchronized, but what if, for example, the secretary adds/updates a record, how is that passed to the others?
3. I believe the server queues tasks and redistributes them in order to the other devices. What if one device send a modification to the server but then goes offline and other events happen. Can the app continue to function locally (continue modifying, etc.) without being jammed up?

 

Thank you for the thoughtful questions — these are exactly the kind of discussions that help clarify design choices.

Let me address them step by step.

1. Is there a complementary “publisher” part like NWP?

Baruch is not designed as a direct clone of NWS/NWP.

The focus is different. Baruch separates:

• planning coordination (appointed brothers)

• local personal data handling

• optional distribution mechanisms

There is no central cloud profile containing personal data for each publisher.

If publishers access information, they only receive the planning data relevant to them — never the full congregation dataset, and never personal records stored in the cloud.

So in short: Baruch does not replicate the NWP model. It approaches the architecture differently.

 

2. If data itself is not synchronized, how are updates passed?

This is the key architectural difference. Baruch synchronizes:

• planning objects

• anonymous identifiers

• structural changes

It does not synchronize:

• names

• phone numbers

• addresses

• personal notes

Each device maintains its own local mapping between anonymous IDs and personal data.

When the secretary updates a record:

• the structural change is synchronized

• the anonymous ID is referenced

• local devices apply the change against their local mapping

The cloud never stores the identity layer.

 

3. What about offline conflicts and queue handling?

 

Baruch is designed as offine-first. Each device can:

• continue modifying locally

• queue changes

• resolve conflicts based on versioning and timestamps

If a device goes offline:

• it continues functioning normally

• events are queued locally

• upon reconnect, a reconciliation process runs

Conflict handling is deterministic and scoped to planning objects — not personal data.

So the system does not “jam up” if a device goes offline mid-operation.

 

Baruch does not use a publish/subscribe push mechanism. There is no real-time event pushing from the server to clients.

Instead, Baruch uses a pull-based synchronization model. Here is how it works:

• Each device works fully locally.

• Changes are stored locally.

• At regular intervals, the device checks (pulls) whether new events are available on the server.

• If events exist, they are fetched and applied.

• If the device was offline, nothing breaks — it simply pulls pending events when it reconnects.

There is no server-driven push.
There is no dependency on continuous connectivity.

What happens if a device goes offline after sending a change?

Because synchronization is pull-based:

• The device commits its change locally.

• When connectivity is available, the change is transmitted.

• Other devices will only see the change when they perform their next pull cycle.

This means:

• The app continues functioning normally while offline.

• There is no blocking state.

• There is no “jam” scenario caused by missing push acknowledgements.

This is the reason why Baruch doesn't use Pub/Sub. Push systems require:

• persistent connections

• background listeners

• more complex session/state handling

• higher surface for synchronization bugs

Pull is:

• predictable

• resilient

• easier to reason about

• less dependent on infrastructure complexity

For congregation use, simplicity and reliability were prioritized over real-time immediacy.

Near-real-time is sufficient for planning coordination.

[The Andrew]

Jonathan ... excellent work even though its geek speak at least to me.

 

Our congregation in Western Australia has been using NWS/NWP for everything (except Maintenance) for 3+ years now and the entire congregation love using it, even the oldies. In particular the Territory & Map functions for our entire territory which is 90% separate homes, and 10% flats, plus business territory.

 

Thank you for implementing localized device storage like NWS & NWP as it removes the significant concern many appointed brothers have with cloud based programs, let alone issues of cellular unavailability. 

 

IFF we were at some point in the future, trialists of your system:

1) Will it import non-territory data from NWS?

2) Will it also import the territory mapping?

3) If all imported, can it run in parallel with NWS/NWP during the testing phase without interference from each other.

 

Whatever the outcome, all the best in this endevour.

[Jonathan1]

5 hours ago, The Andrew said:

Jonathan... Uitstekend werk, ook al spreekt het geek in ieder geval tot mij.

 

Onze gemeente in West-Australië gebruikt NWS/NWP al 3+ jaar voor alles (behalve onderhoud) en de hele gemeente gebruikt het graag, zelfs de ouderen. In het bijzonder werkt de Territory & Map voor ons hele gebied, dat voor 90% uit aparte woningen en 10% appartementen bestaat, plus zakelijk gebied.

 

Dank u voor het implementeren van lokale apparaatopslag zoals NWS en NWP, want het neemt de aanzienlijke zorg weg die veel aangestelde broeders hebben over cloudgebaseerde programma's, laat staan problemen met mobiele onbeschikbaarheid.

 

ALS we op een gegeven moment in de toekomst proef-aanhangers van jouw systeem waren:

1) Zal het niet-territoriale data importeren van NWS?

2) Zal het ook de territoriale toewijzing importeren?

3) Als ze allemaal geïmporteerd zijn, kan deze parallel draaien met NWS/NWP tijdens de testfase zonder interferentie van elkaar?

 

Wat de uitkomst ook is, veel succes met deze onderneming.

 

Thank you for sharing your experience.
It’s genuinely encouraging to hear that your congregation has found a system that works well — especially when even older publishers are comfortable using it. That is exactly what any tool should achieve.

Regarding your questions:

 

1) Will non-territory data import from NWS?

Yes — import functionality for non-territory planning data is part of the roadmap.

The intention is to support migration in a way that:

• minimizes re-entry of information

• respects existing structures

• allows gradual testing

The focus is primarily on structural planning data (assignments, roles, scheduling elements), not on centralizing personal records.

 

2) Will territorial assignments import?

Territory management is currently placed toward the later stages of the roadmap.

The reason is practical: in many congregations, territory handling is already managed through dedicated tools (for example Territory Helper), while the most immediate need I observed was in core congregation planning.

My initial development focus has therefore been on essential scheduling and coordination within the congregation.

 

Regarding import specifically:

Baruch’s import capability depends on what NWS makes available through its export functions.

I understand from their website that they support data import and export to other systems. The exact scope and structure of exported data naturally determines what can be imported reliably. 

Because Baruch is independent, integration depends on:

• what data is exportable

• how it is structured

• and whether that structure remains stable

This part is not entirely under my control.

That said, the import/export module in Baruch has been designed with integration in mind. It is modular and prepared to support structured data exchange with other systems where technically feasible.

So while territory import is not the first priority, the architectural foundation is prepared for it.

 

3) Can it run parallel without interference?

Yes. Baruch is designed to:

• Run independently

• Use its own local storage

• Avoid modifying or accessing NWS/NWP data

There is no shared database. No shared cloud. No integration dependency.

A congregation can run Baruch in parallel for weeks or months during evaluation.

Nothing in NWS/NWP is altered or affected.

Parallel evaluation is not only possible — it is encouraged.

[Jonathan1]

A Look Behind the Scenes: How Baruch Handles Import & Integration

Several brothers have asked whether Baruch is prepared to integrate with other systems like NWS, or whether it’s a closed ecosystem.

I’d like to give you a small “behind the scenes” look at how Baruch is actually built.

Import & Export Was Designed From Day One

Baruch’s import system is not an afterthought. It is built as a modular pipeline with clearly defined responsibilities:

• Dedicated ImportContext

• Individual ImportHandlers

• A structured Importer pipeline

• Import types separated per domain (Congregation, Planner, Publisher, Territories, etc.)

• Diagnostics and progress reporting built in

Each importer implements a specific ImportType and processes data through a chain-of-responsibility pattern. That means:

• Adding a new external system is simply a matter of writing a new importer module.

• The core system does not need to change.

• The architecture is open for extension, closed for modification.

In other words: Baruch is prepared to connect.

 

Proof That It Works: The “SampleData” Module

Now here’s the interesting part.

You can see that this architecture actually works in the SampleData component inside the Import module.

Instead of hardcoding demo content, I deliberately use the same import pipeline to:

1. Generate a complete fictional congregation

2. Structure it as if it came from an external system

3. Import it through the exact same import process

So internally, Baruch treats SampleData as if it were importing from something like NWS.

The only difference is that instead of reading a real export file, it reads generated test data.

This means:

• The import engine is production-ready.

• It is not theoretical.

• It is used daily during development.

• It is capable of handling fully structured congregation data.

Because this approach proves three things:

1. Baruch is integration-ready
2. Migration does not require reqwriting the core
3. You can test Baruch with a fully configured congregation

When you install Baruch, you can load a complete fictional congregation: 

Publishers, Assignments, Territories, Schedules, History, Reports. 

Everything is populated instantly.

You don’t have to start from zero to evaluate the software.

 

I didn’t want Baruch to become a closed island.

From the beginning, I knew congregations may:

• Want to migrate gradually

• Want to experiment without risk

• Want to test with realistic data

• Want interoperability in the future

So I built the import/export layer as infrastructure — not as a utility.

If you ever wonder whether Baruch can connect — the answer is:
The plumbing is already there.