Advanced Application Model & P2P Distribution

[ToddHebebrand]

As for the testing...of course! Thank you for providing this!

I have to switch my reverse proxy to NginX because I am not deploying this on a VPS but behind a firewall doing NAT and I dont want to have a reverse proxy proxying to another reverse proxy (Caddy) and my current reverse proxy does not seem to support URL rewrites which this seems to require for the backend to be referenced at /api so I will be definitely testing this...

I originally typed the following out myself, but then I summarized with AI because I had a pressing matter, so please still consider the content...

---

💡 Feature Request Summary

Advanced Application Model & P2P Distribution

First off — excellent work. What’s already been delivered is a huge step forward and genuinely refreshing. The following are optional future enhancements inspired by long-term real-world endpoint engineering experience (13+ years), but not required for success.

---

🚀 Core Enhancement Themes

1. NATS-Based Agent Communication

• Use NATS (pub/sub) for agent ↔ server and agent ↔ agent communication

• Enables:

  • Real-time task distribution

  • Event-driven execution

  • Scalable, reliable messaging backbone

  • https://nats.io/

---

2. Advanced Application Deployment Model

Inspired by:

• MECM / SCCM Application Model
• Novell ZENworks Bundles
• Action1 deployment workflows

📦 Application Object Hierarchy

Application
 ├── Metadata + Configuration
 ├── Deployment Steps
 └── Versions
      ├── Content
      └── Command lines / install logic

🔧 Deployment Capabilities

• Support simple and complex multi-step deployments

• Steps may include:

  • Download Content
  • Execute Process
  • Run Script
  • Download File

---

3. Conditional Logic Engine

Support dynamic deployment conditions, including:

• IP Address / Subnet
• Internet connectivity
• Script return values
• Registry checks

With logical grouping:

Condition Groups
 ├── AND / OR logic
 └── Nested condition evaluation

---

4. Deployment Waves (Progressive Rollout)

Allow phased deployment waves:

• Wave 1 → initial rollout
• Wave 2 triggers only if X% success threshold (e.g., 75%)
• Controlled, safe progressive rollout

---

5. User Experience Enhancements

Add an endpoint user experience layer:

• Tray icon / agent UI

• Notifications for:

  • Install progress
  • Required reboot
  • Completion

• Optional Application Store:

  • On-demand installs
  • Required/available applications

---

📡 Peer-to-Peer (P2P) Content Distribution

🎯 Goal

Improve bandwidth efficiency and speed for large software deployments.

🔁 Model (inspired by Action1)

• Agents download content segments
• Peers share segments locally
• Each endpoint assembles full package

Benefits

• Massive reduction in WAN usage
• Faster deployments per site
• No dependency on distribution servers

---

🌐 Virtual Office Concept (Action 1 does NOT do this)

Enhance P2P distribution by grouping endpoints into logical distribution zones:

Virtual Office Definition

A “Virtual Office” is defined by:

• Public IP(s)
• Associated internal subnets specified by IP range or CIDR notation

Behavior

• Endpoints behind the same circuit/public IP:

  • Share content across multiple local subnets
  • Reduce duplicate downloads per site
  • Action1 can only peer within the same subnet.

---

📷 Reference UI / Workflow Concepts

---

🔗 Reference: Action1 P2P Model

Private P2P Software Distribution Technology
https://www.action1.com/documentation/p2p-sharing/

---

✅ Summary of Value

These enhancements would provide:

• Enterprise-grade application deployment
• Highly efficient bandwidth usage
• Safe, phased rollout controls
• Rich end-user experience
• Fully cloud-native architecture with no single points of failure

---

Again — current progress is already excellent. These are future ideas, not blockers.

Originally posted by @freedbygrace in #93

[freedbygrace]

Looking forward to this...might need some assistance to get things fully working, then I can take findings to make things easier for future users...In any case, as far as the script editors, the pictures I showed are old and basic...there is another open source app called "Dockhand" which helps with Docker management...there in browser code editor looks like the following...I think Breeze should be close to or inspired by the following...Just a thought of course.

[SemoTech]

@freedbygrace have you looked into Portainer?

[freedbygrace]

Oh yes of course! I have used it for several years since I first got into this stuff, but now I am realizing that outside of CLI approach, Dockhand is muuuch better and I would probably say Komodo after that. Why do you ask?

[SemoTech]

Oh yes of course! I have used it for several years since I first got into this stuff, but now I am realizing that outside of CLI approach, Dockhand is muuuch better and I would probably say Komodo after that. Why do you ask?

No reason I just thought to make you aware. I am looking at Dockhand now... interesting....

[ToddHebebrand]

Converting this to a Discussion — it's a great collection of future feature ideas rather than a bug to fix. Moving to Discussions so the community can upvote and discuss individual items.

[bdunncompany]

Good ideas here. Action1 definitely nailed it here, especially when having to deal with clients where connectivity is an issue.

[ToddHebebrand]

@freedbygrace — circling back on this: we took these seriously and ran a full architecture feasibility pass.

The exciting realization is that several of these don't need to be separate features. P2P distribution, the Virtual Office concept, and Zero-Trust Network Access (reaching a device's services without a VPN) all want the same foundation: a strong per-device and per-user identity, plus a NAT-traversing peer-to-peer network fabric. Build that fabric once and the rest become consumers of it.

Roughly how we're scoping it:

1. Identity first — every agent and technician gets a strong cryptographic identity, with SSO (Entra/M365) tying in the user dimension, so access is decided by "who + which device + where," not static lists.
2. The fabric + ZTNA — a WireGuard-based mesh so a tech can reach an endpoint's services directly and securely. The foundation-defining piece.
3. Virtual Office — your idea, and we think it's the right refinement: group endpoints by site/circuit (public IP + internal subnets) so peers share across subnets at a location, not just within one.
4. Content distribution — once the fabric exists, P2P patch distribution and native file sharing ride the same transport: download once per site, share locally, permissions driven by the same identity model.

A couple of the other items map onto adjacent work — the advanced application/deployment model builds on our software catalog, and "cloud file sharing" in the Microsoft sense is being handled via a separate OneDrive/SharePoint helper.

No timeline commitments — this is a foundation we'd rather get right than rush — but these weren't lost. The endpoint-engineering perspective here genuinely shaped how we scoped it. Keep them coming.

[freedbygrace]

Hey! So glad to hear this! I think I sent you a connection request already, but lets do a zoom or something because I would love to hear about where you want to head overall with this and expand into some more color around your thoughts on what you shared here!