07:05:26 Hey is something wrong with the Monero GitLab? I am not able to access it. 07:05:52 <3​21bob321:monero.social> its down 07:06:06 Yes 07:06:19 ^ 07:19:39 GM 07:20:39 I have a question or two for every dev available on this planet 07:20:59 Can a disabled or special person run a Monero public node? 07:21:09 Thank you in advance everyone 07:24:31 How is tour question in _any_ way related to development? And why is it directed at _every_ dev? 07:24:45 Your* 07:26:10 Or, to put it differently: this room is for development, not for general questions. Your question is not regarding development, and is very much a "general" question. It's also not something that only a dev can answer 07:26:31 ask your question in [#monero:monero.social](https://matrix.to/#/%23monero:monero.social) 07:27:01 Sorry my bad 16:05:18 .merge+ 10428 10457 10492 10494 16:05:18 Added 16:17:52 .merge+ 10460 16:17:52 Added 16:33:23 https://github.com/monero-project/monero/blob/master/src/p2p/net_node.h#L76C5-L76C34 16:33:43 This line is giving me some issues, as it would be helpful to have other zones' endpoint not be SOCKS ones 16:34:47 What would be the best thing to put here instead? `epee::net_utils::network_address`? 16:36:59 Hopefully I don't have to change anything in epee 16:40:29 is that only used for `get_proxies` ? 16:41:39 I honestly cannot tell 16:42:12 yeah its only used for configuration 16:42:24 either make it a variant or just get a separate function for this 16:43:54 you (probably) have to setup a custom m_connect function for SAM, so the caller needs to know what type anyway 16:58:14 I could be wrong, but it seems that using a variant would require me to change all of the other code that uses `m_proxy_address` because it expects it to be SOCKS 16:58:37 Would it be an option to add a separate field in `proxy` for the SAM address? Or would that not work 17:02:08 *by SAM address, I mean the (local) IP of the router 17:07:34 you can probably just rename the socks endpoint to something else, and then create a new enum for sam+socks (to replace ver in socks endpoint) and then write a custom connect function 17:08:11 Even if you don't use the other fields is probably not a big deal 17:09:20 Or no even easier 17:10:17 The connect function handles it all, just create a new field in network_zone and then pass it in the connect handler 17:11:01 Don't even touch get_proxies, just create a parallel function but error if socks and Sam are configured on i2p 17:12:50 You could make m_proxy_address a variant if you wanted to save space, but theres few zones at runtime so it's not a big deal 17:18:05 And to clarify, you'd be writing a separate `sam_connect_internal` function that gets set to `m_connect_func` whose implementation uses i2p Sam whatever from the network_zone instance 17:25:29 So basically, there would be a separate `m_sam_address` (the IP/port of the router), and then `sam_connect` is used instead of `socks_connect` 17:26:01 I already have those functions made, so that will probably work 17:27:13 The thing I have in mind (what would make the most sense from a UX perspective) is to have the `--i2p-sam` flag override `--tx-proxy` and `--anonymous-inbound`; this is currently done using an if-else statement that only touches `get_proxies` if SAM isn't set 17:28:26 So that might conflict with it 17:28:57 Seems better to just error out, the person might be confused by the options 17:29:05 Whoever sets the connect function last will take precedence basically 17:29:54 Okay, thanks. I'll see if I can manage to wrap my head around this ;) 17:48:09 No way, it actually kind of works now 17:49:01 The session doesn't get established, but still :))