futurechimp commented 1 year ago

At the moment, the Nym native client is hardcoded to listen to host 127.0.0.1. We set it up this way to make a conservative security assumption, essentially "don't open up a listening port to the world".

We're getting developer feedback now that this is a problem in a Dockerized environment, where it can be convenenient to listen on 0.0.0.0.

I think it makes sense to keep the default behaviour (start the client bound to 127.0.0.1) but add a new option in init so that if needed, the user can specify the listening address according to their needs (0.0.0.0, 1.2.3.4 etc).

sven-hash commented 1 year ago

Yes please, we would love to see this happened

I think it makes sense to keep the default behaviour (start the client bound to 127.0.0.1) but add a new option in init so that if needed, the user can specify the listening address according to their needs (0.0.0.0, 1.2.3.4 etc).

This is a good solution to be able to specify when run the nym-client to specify --init <listening address>

There was a feature request here: https://github.com/nymtech/nym/issues/1674

gyrusdentatus commented 1 year ago

At the moment, the Nym native client is hardcoded to listen to host 127.0.0.1. We set it up this way to make a conservative security assumption, essentially "don't open up a listening port to the world".

We're getting developer feedback now that this is a problem in a Dockerized environment, where it can be convenenient to listen on 0.0.0.0.

I think it makes sense to keep the default behaviour (start the client bound to 127.0.0.1) but add a new option in init so that if needed, the user can specify the listening address according to their needs (0.0.0.0, 1.2.3.4 etc).

Nym release 1.1.9

At the moment, the Nym native client is hardcoded to listen to host 127.0.0.1. We set it up this way to make a conservative security assumption, essentially "don't open up a listening port to the world".

We're getting developer feedback now that this is a problem in a Dockerized environment, where it can be convenenient to listen on 0.0.0.0.

I think it makes sense to keep the default behaviour (start the client bound to 127.0.0.1) but add a new option in init so that if needed, the user can specify the listening address according to their needs (0.0.0.0, 1.2.3.4 etc).

Very good choice! And also great to listen to some feedback! This is a 3 part comment, I hope you find it constructive.

Section 1 is directly related to the changelog and why it’s really great this was released.
Section 2 is a follow-up dev-rel feedback, just food for thought, but we can certainly make a follow up where I would explain it in depth.
Section 3 is my dillema: What client do I use now? Now it is even more paralazing for me, because you fixed this obstacle :D ...

Section 1

Here is a quick note about my 3 years of struggle with Docker and Nym :) - the worst is the `run` and `init` parts not being one command as ...issue from someone else from 2020 (can dig it out later)

Why I use Docker? To test stuff and break stuff before I knowsomething somehow works. So it saves me time, just like using chatgpt for a help there and there ...:PPP

Otherwise with Docker it is a pain in the ass to set up things, making you spent time with Docker that should save you time WAY more than actually doing the thing it was made for - to save you time during development.

I think, overall, anyone who runs something that is not, well python or JS, should be able to set up whatever they want without going deep into the code Rust rabbithole or even having to make their own fork to change code themselves. Yes I know, we have a SDK now, it is great, but stil a lot of work ahead, but so far so good!

SECTION 2

→ sidenote and feedback/dev-rel follow-up

Disclaimer:

While this comment may not be directly related to the current release - I wanted to take a moment to share some thoughts on the longer-term suggestions, I think it is complementary to my earlier feedback interview.

I just had a few quick ideas that I wanted to explore and share, so here are a few topics that I think are worth exploring:

This is 6-12 months, the first suggestion could be even 2-5 years.

let anyone decide themselves how they want to run their system. Using NYM with something that is more high-level full-suite would be super cool. Think cargo instead of rustc when you build stuff.
chaining run and init into one command. This was always a problem and will cause even more problems when we move for example to k8s. --- why would this be an issue to implement or what is your reasoning behind it? I hate to init something for testing on each new machine I get. I want to be able to spam stuff I need as quickly as I can.
more in-depth docs on your changes with Sphinx and others, coco, various new nym-side stuff. I can't do it, because I know only that much. You guys know more than anyone in the world reg these topics.
- explain somewhere how the Sphinx is even created for example.
in general - every a bit more complex topic should be well documented, because obviously the nymsphinx is not the same thing as what is in the original paper.
would be lovely to have some educational resources - just pointing to a good source of information, read that IETF, docs for that crate, book… **Making a list of further reading on each essential topic is in my opinion crucial if we want to truly make this work.

Here is an example of what I was reading a few minutes ago. This is enough. Just say “Hey H., go read this and then come back and try to ask again” and I do not need to hear anything more :) …**

# This is a must read for anyone who wants to truly develop a secure, bleeding-edge apps on top of NYM

Read this:

BCP 230
RFC 8900
IP Fragmentation Considered Fragile, SEPTEMBER 2020
<some-url> for IETF .txt

dedicated chats for contributors - with limited access. INTERNAL. Other people like @cgi_bin , myself or dozens of other people I can think of could vet these people in some “stupid” DAO way …? You will need this anyway for vuln disclosures with dedicated email that goes directly into your whatever matrix chat: Let's say I am someone unknown, found a really breaking exploit, how do I reach you?
- this means I would like to see 2 company-invite-only channels for bug reports that are too sensitive, with your custom template. && dedicated developer channel, invite only to chat about the technical stuff above. I am well aware I kept asking you and Andrew stupid questions all the time, but I think I can now turn it into somewhat coherent message that explains very well what I mean.
- let the devs ask research questions - more in touch with the r&d. Yes, I know how A and D are really busy and all, but we need this. A lot of good devs left the project because of this. Can explain more in depth somewhere else.
Show your faces NYM! Make a vlog or smth, I dunno. I certainly do not mean “promo” material for normies, but for the people that build stuff.

This is after-all, not only about money, if it was, I would be doing some gigs that pay really well, but I would not be working/trying to work on something that could save lives(oopsie a little cliche here) just make the totally broken thing we call internet a better world.

AMAs are an over-used format and people are not really that engaged anyway.

You can even pre-record stuff for AMA that would run over a month perhaps (The questions).
Then answer the best questions in a video-format with high video and mainly audio quality.
I don't get why people are so obsessed with some live talks …(I would love to have the audio of @futurechimp explaining a gardenhose to tor. Even my mum would understand how tor works better than most of the population haha!!!)…… Imagine Master Dave doing live cam scribbles or using animated objects. He is one of the best educators, I have ever seen. There are only few people that can explain these complex topics so even my mum or my 6 yo niece would understand it.

SECTION 3:

@futurechimp @mfahampshire I would love to hear your feedback.

Decision paralysis with clients for mid-term:

email suite built on top of NYM. Time: 1-2 years with a lot of new functions. Think Protonmail webapp.

We agreed with MX (now I realize this is a funny joke when I talk about email, hope you get it!)

But now, seeing this changelog - I have even greater dillema which client to choose for N Y M S T R email:

decided to ...well ok, I will do the easy thing. Route it all through socks5, came here because it seems my --version 1.1.4 is not compatible with the gateways, so I wanted to update.

Now I see this and thinking again....hmmm well, maybe I could use the native client for everything, just spam some containers and serverside it is done and sexier, more future-proof?

For me it is a total analysis paralysis which of the 3 clients to choose at this point.

This long comment started here, at section 3 and here it ends. Hope it is something that will add value and help the cause. Thanks if you made it so far.

Cheers, H

PS

Written from stupid iOS app (not sure where the preview is so excuse me for any formatting mistakes. This was not enhanced by chatgpt. It just told me my suggestions are sh*t. So I added a disclaimer at SECTION 2)

gyrusdentatus commented 1 year ago

I am wondering...is this comment of mine above stored in root .git folder or anywhere? Or just Github? I will not Googlebing such a stupid thing.

nymtech / nym

Add `host` option to client init #2912

Nym release 1.1.9

Section 1

Here is a quick note about my 3 years of struggle with Docker and Nym :) - the worst is the `run` and `init` parts not being one command as ...issue from someone else from 2020 (can dig it out later)

SECTION 2

→ sidenote and feedback/dev-rel follow-up

Disclaimer:

This is 6-12 months, the first suggestion could be even 2-5 years.

SECTION 3:

Decision paralysis with clients for mid-term:

email suite built on top of NYM. Time: 1-2 years with a lot of new functions. Think Protonmail webapp.

nymtech / nym

Add `host` option to client init #2912

Nym release 1.1.9

Section 1

Here is a quick note about my 3 years of struggle with Docker and Nym :) - the worst is the run and init parts not being one command as ...issue from someone else from 2020 (can dig it out later)

SECTION 2

→ sidenote and feedback/dev-rel follow-up

Disclaimer:

This is 6-12 months, the first suggestion could be even 2-5 years.

SECTION 3:

Decision paralysis with clients for mid-term:

email suite built on top of NYM. Time: 1-2 years with a lot of new functions. Think Protonmail webapp.

Here is a quick note about my 3 years of struggle with Docker and Nym :) - the worst is the `run` and `init` parts not being one command as ...issue from someone else from 2020 (can dig it out later)