All Activity

Tuesday, February 17 [Saul] then got up and was baptized.—Acts 9:18. What helped Saul to get baptized? When the glorified Lord Jesus appeared to him, Saul was blinded. (Acts 9:3-9) For three days, he fasted and no doubt meditated on what he had just experienced. Yes, Saul became convinced that Jesus was the Messiah and that his followers practiced the true religion. There are lessons that we can learn from Saul. He could have allowed pride or fear of man to prevent him from getting baptized. But he did not allow that to happen. Saul was willing to become a Christian even though he knew that he would be persecuted. (Acts 9:15, 16; 20:22, 23) After his baptism, he continued relying on Jehovah to help him endure various trials. (2 Cor. 4:7-10) Your getting baptized as one of Jehovah’s Witnesses may lead to tests of faith or trials, but you will have help. You can be confident of the unfailing support of God and of Christ.—Phil. 4:13. w25.034 ¶8-9

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.

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? 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? 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 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.

Hi, I had the same problem. Many siblings could no longer log into the app. I solved it this way: log into NWS from your PC, then click on the cell phone icon on the left and select "People in the App." Once you see the entire list of siblings who have installed the app, click on their name once and click "Refresh Person." Close the message that appears and click "Send App Data." Once you've done this, everything will work. Click "Apps" > "People in the App" Select the person Click "Refresh Person" Click "Apps" > "Send App Data" > "Prepare and Send" button.

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

Where exactly in NW Scheduler are you seeing your field service groups mixed up?

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.

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

I started the new topic on

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: The change is written to the local database A domain event is created The event is stored in a local Outbox Event Store The Outbox pushes anonymous events to the server 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.

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

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.

We have plan to visit Australasia Brancj in 2029 - i hope we'll manage to both save money and still see the sets

You have a github?

Yes very cool 😀 Nothing happened neither at 1111 🤐 That happened on 24 Feb 2025 had to wait a while, but it happened 😍 👍 👍 On the List are: French Français French (Benin) Français (Bénin) French (Canada) Français (Canada) Now we also have: French (Côte d'Ivoire) Français Ivoirien The number 2000 has been mentioned before, but I'm not going to hold my breath for that. 😅

Friends, Does anyone have an idea on how to rearrange the service groups in sequence by name, if they are mixed up, such as Group 1, Group 7, Group 2, Group 11, etc., in the NW Scheduler?

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

THANKS sister Barbara 😊

Yes.. you got Helen .. @Dustparticle.. Those pushing of KoTn and Kots are fulfilling the prophecy ... Im unemployed now for almost 2 months and my friend was fired 3 days ago... And lots of my friends are suffering, I want the new system for everyone..

Thank you very much @Dré. That's him, Brother Claudius Johnson. An interview I enjoy listening to again.❤️

Right there with you, Pauline.

Select Your Language Languages: 1,111

Never have I ever watched Survivor, Housewives, or Naked and Afraid