feat: support UDP proxy of port 2022 and 2023 for P2Panda apps #70
Reference in New Issue
Block a user
No description provided.
Delete Branch "support-p2panda"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Support P2P communication between P2Panda Apps
Apps built with the set of P2Panda libraries perform P2P communication over two UDP ports. The default ports for these are 2022 and 2023.
There aren't really a lot (any?) P2Panda web apps out there, most are desktop or mobile apps.
So, this change is being specifically request by the LoRes Tech project in order to support our LoRes Node app. We have a recipe drafted for this here and we will push that to the catalogue once this change is in.
It seems better to make this kiwix change as general as possible, which is why we called the flag
P2PANDA_ENABLEDrather thanLORES_NODE_ENABLED. In practice if there was a larger ecosystem of such apps, we'd probably need to make the actual port numbers configurable.LGTM 🫶
Seems like you could also support an env var which is specific for your project as a duplicate env var that does the exact same thing? Only if you want that on the LoRes Tech ofc and it's handy to have some familiar naming for end-users. Just need to extend all conditional clauses to check both env vars...
@ -37,6 +37,12 @@ entrypoints:gitea-ssh:address: ":2222"{{ end }}{{ if eq (env "P2PANDA_ENABLED") "1" }}Oh wait a sec, you need to bump the config version:
For context: the env var need to be increased rverytime the file gets changed. This is necessary for all template files
Ok, I've bumped this. I've also bumped it in the drone file, which was a bit out of date, hopefully that works.
Very cool to see p2panda and lores tech here 😍
I don't think we need that, we're not hiding P2Panda as an abstraction, and I think it makes sense for our users to know that's why we're exposing those ports.