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
It's good for nodes to have an https:// url for the api so that a Link ContextId operation doesn't reveal the link between a BrightID and a ContextId. Also so that BrightIDs aren't associated with IP addresses.
Another option is for clients to know a node's public key and encrypt the canonicalized json using it, but I think https:// also covers data that is returned that might also link a user's BrightID to an IP address and also some clients work better with https:// so it's nice for a node to provide it.
How to implement the change
I think for supporting HTTPS, we should consider using nginx that is not in a container. We can write instructions for installing nginx and configuring it with letsencrypt. They will obviously need to have registered domain for the certificate.
Having another nginx in front of the nginx container should be easier for users to understand and configure than bringing the nginx out of its container. It also means fewer container ports need to be published on the host.
The text was updated successfully, but these errors were encountered:
Reason for the change
It's good for nodes to have an https:// url for the api so that a Link ContextId operation doesn't reveal the link between a BrightID and a ContextId. Also so that BrightIDs aren't associated with IP addresses.
Another option is for clients to know a node's public key and encrypt the canonicalized json using it, but I think https:// also covers data that is returned that might also link a user's BrightID to an IP address and also some clients work better with https:// so it's nice for a node to provide it.
How to implement the change
I think for supporting HTTPS, we should consider using nginx that is not in a container. We can write instructions for installing nginx and configuring it with letsencrypt. They will obviously need to have registered domain for the certificate.
Having another nginx in front of the nginx container should be easier for users to understand and configure than bringing the nginx out of its container. It also means fewer container ports need to be published on the host.
The text was updated successfully, but these errors were encountered: