Fully offline hosting

[CzarofAK]

are there plans to run this software entirely offline?
Like in a KP Rück on a ThinClient with its own router to connect laptop?

Level 1:
This would required to have an offline user- and map-management.
Level 2:
Further a offline (via e.g. usb-stick) syncronization between different KPs.

To me, a hosted systems has the same flaws as IES or Lafis, that they are hosted on servers somewhere.
Usually the internet connection is the first things being degraded in an emergency.

[nimdanitro]

Hi @CzarofAK

Thanks a lot for your great input here.

Level 1:
Absolutely, except for the map module (which still depends on loading the maps from map.geo.admin.ch) everything should already work fully offline. Some organizations we support are having a dedicated instance as fallback on a Rock Pi or a Raspberry Pi. The only piece relevant to make sure to get right is the authentication. In the example folder you find a docker compose consisting of a dex IDP component which can be used as a local IDP with static usernames / passwords.
For the offline map access, we did already experiment with hosting and running them locally, here we made some compromises and e.g. only make the vector map available and not the satellite map. So there is a slight decrease in user experience in favor of availability. When a connection to the internet exists, all map styles are available. This feature should be available in a few months in general access.

Conceptually, we envision that SitRep instances should be decentralized and work in a federated way. This means that Sitrep instances can be federated across each other (for individual incidents in a unidirectional sync mode or in a full bidirection mode). Assuming you have your main SitRep application and your local fallback SitRep instance. While there is a connection between them, we envision that they can automatically sync all incidents and all corresponding events automatically in a bidirectional way. If the connection goes down, you can continue working on the local fallback instance. If connection is restored the events are resynced and should be eventual consistent again.

The unidirectional sync mode is thought for aggregating up underlying organizations up to higher level (e.g. cantonal) sitrep instances. We strongly believe this is a way more resilient approach than relying on centralized applications like Lafis or IES.

Level 2:
We did not envision that in such a way. Can you elaborate on the specific use case here?

[CzarofAK]

Thanks for your answer, it makes me confident that you aim the right way with the project.

About Level 2. I thought about having a KP Rück (GFO or Zivilschutz KP) reporting to KFS, or KP Front to KP Rück.
Instead (besides of key messages) send an hourly update via a media, instead of telephone or radio.

• Tbh, we should learn first how to properly apply this software base situation management before thinking about sync... ;-)

[nimdanitro]

@CzarofAK ah yeah, I get what you mean with Level 2 now. E.g. have your incident on sitrep and then basically press "Export" and it compiles all required information and would create some PDFs with resources, people, maps, journal and maybe even a ZIP file to import on another sitrep server if no automatic sync is configured.. I like this idea.

Btw. the non-profit organisation F-ELD is happy to assist you and your org in on-boarding and working with sitrep. We have material ready for your officers and also some learning modules for the repetition courses with the wider team. Free free to reach out anytime to info@f-eld.ch.