You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, mostro handles admin commands using NIP-59 nostr events. While this setup is functional, there are some compelling reasons to consider implementing a more direct communication method (i.e., not relying solely on nostr):
Local Development Environment: Debugging would become significantly easier with a direct line of communication to the mostrod instance. With so many moving parts in the current nostr-based setup, pinpointing errors or inefficiencies is challenging.
Efficiency for Admin-Oriented Apps: For systems like Start9 or Umbrel, where an admin app might run on the same hardware as the mostro instance, going through nostr introduces unnecessary complexity, latency, and potential unreliability. Direct communication could streamline this interaction, making the admin experience smoother and more efficient.
Additional Considerations
This proposal does not suggest replacing nostr-based admin commands but rather augmenting them. Nostr-based commands would still be useful for scenarios requiring remote administration, particularly when the admin app and the mostro instance are not co-located.
An argument can be made for the benefits of keeping communication nostr-only, as it inherently ensures that any admin app would be remote-friendly and maintain the security posture of the mostro instance, avoiding potential issues like IP leakage.
The text was updated successfully, but these errors were encountered:
I've been giving this additional thought and I think that: maintaining a second interface will imply additional dev overhead and it's likely not that valuable for the time being.
In the future, it could be reasonable to try to detach the nostr interface from mostro. Mostro would have a single RPC API which is then used by the nostr module to communicate to the 'outer world', but could also be used directly if needed. This would also 'open' the design to have different multiple communication channels available if the mostro operator desires.
I actually think this is a good idea. An admin comms channel is a 1-to-1 that doesn't need to go over nostr as it gains nothing from it. I'm not sure how much work overhead it would require though.
Currently, mostro handles admin commands using NIP-59 nostr events. While this setup is functional, there are some compelling reasons to consider implementing a more direct communication method (i.e., not relying solely on nostr):
Local Development Environment: Debugging would become significantly easier with a direct line of communication to the mostrod instance. With so many moving parts in the current nostr-based setup, pinpointing errors or inefficiencies is challenging.
Efficiency for Admin-Oriented Apps: For systems like Start9 or Umbrel, where an admin app might run on the same hardware as the mostro instance, going through nostr introduces unnecessary complexity, latency, and potential unreliability. Direct communication could streamline this interaction, making the admin experience smoother and more efficient.
Additional Considerations
The text was updated successfully, but these errors were encountered: