Hard to contribute here, but has anyone looked at fixing the build?

[michaelwschultz]

I noticed a bunch of exit points around my neighborhood but wanted to see a map. Seems like this has been broken for almost 2 years.

[bennlich]

Heya @michaelwschultz . Yes, the project has been pretty quiet since covid started (~2 years ago now, wow). I can't speak for others, but I know I personally ran out of bandwidth at the time.

I'd love to transfer the knowledge I have to someone with some web dev experience looking to picking it back up. Let me know if you're interested in helping to get this back online.

P.s. Thanks for opening up those https issues back in November.

[bennlich]

Just opened https://github.com/sudomesh/monitor/issues/58

[mattcodenow]

How about a desktop app that isn’t dependent on a server environment? I’m willing to volunteer.

[bennlich]

@mattcodenow The monitor keeps track of a log of events, so it needs a database and a reachable IP address to receive POSTs.

This is currently documented in the repo readme in words, but it would be nice to add a picture: https://github.com/sudomesh/monitor/issues/59

[matthewstewart]

Could we DNSLink to a IPFS CID and use p2p instead of being dependent on the POST CURL? The subdomain could point to a hash and remove the cost of web hosting. Electron has electron-store for key/value storage so db could be local storage.

On Fri, Feb 25, 2022 at 8:15 PM Benny Lichtner @.***> wrote:

@mattcodenow https://github.com/mattcodenow The monitor keeps track of a log of events, so it needs a database and a reachable IP address to receive POSTs.

This is currently documented in the repo readme in words, but it would be nice to add a picture: #59 https://github.com/sudomesh/monitor/issues/59

— Reply to this email directly, view it on GitHub https://github.com/sudomesh/monitor/issues/57#issuecomment-1051562535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYZTP2STGUKC2GJ3DOPETLU5BHV5ANCNFSM5PLVD7QQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mattcodenow]

The exit nodes that periodically execute post-routing-table.sh are sending a plain text payload via CURL to a central location, being the monitor express web server, e.g. https://peoplesopen.herokuapp.com/api/v0/nodes . The monitor app itself has other options of communicating rather than REST and an aggregation of NoSQL db records, seems overkill for something that could fit in a JSON array of objects. In terms of persisting an array of JSON, that would be as simple as using an IPFS pinning service, pinning an express API to a hash, and using a filename query on the ipfs url to get the dynamically changing peer to peer JSON array of objects containing the equivalent of the MongoDB hook up you are relying on. Hypercore and Hyperbee or Hyperdrive can be used in the same fashion for a more secure, single writer p2p solution. Check out hyperspace.

On Fri, Feb 25, 2022 at 8:15 PM Benny Lichtner @.***> wrote:

@mattcodenow https://github.com/mattcodenow The monitor keeps track of a log of events, so it needs a database and a reachable IP address to receive POSTs.

This is currently documented in the repo readme in words, but it would be nice to add a picture: #59 https://github.com/sudomesh/monitor/issues/59

— Reply to this email directly, view it on GitHub https://github.com/sudomesh/monitor/issues/57#issuecomment-1051562535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATG6WRY7K6ILLE6BCUGTZT3U5BHV3ANCNFSM5PLVD7QQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[mattcodenow]

Happy to demonstrate and PR if you have a preference Benny.

On Fri, Feb 25, 2022 at 8:54 PM Matthew Stewart @.***> wrote:

The exit nodes that periodically execute post-routing-table.sh are sending a plain text payload via CURL to a central location, being the monitor express web server, e.g. https://peoplesopen.herokuapp.com/api/v0/nodes . The monitor app itself has other options of communicating rather than REST and an aggregation of NoSQL db records, seems overkill for something that could fit in a JSON array of objects. In terms of persisting an array of JSON, that would be as simple as using an IPFS pinning service, pinning an express API to a hash, and using a filename query on the ipfs url to get the dynamically changing peer to peer JSON array of objects containing the equivalent of the MongoDB hook up you are relying on. Hypercore and Hyperbee or Hyperdrive can be used in the same fashion for a more secure, single writer p2p solution. Check out hyperspace.

On Fri, Feb 25, 2022 at 8:15 PM Benny Lichtner @.***> wrote:

@mattcodenow https://github.com/mattcodenow The monitor keeps track of a log of events, so it needs a database and a reachable IP address to receive POSTs.

This is currently documented in the repo readme in words, but it would be nice to add a picture: #59 https://github.com/sudomesh/monitor/issues/59

— Reply to this email directly, view it on GitHub https://github.com/sudomesh/monitor/issues/57#issuecomment-1051562535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATG6WRY7K6ILLE6BCUGTZT3U5BHV3ANCNFSM5PLVD7QQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[michaelwschultz]

@bennlich @mattcodenow any update here? Just curious. Seems like Matt has an interesting solution.