Matt Palmer on Nostr: nprofile1q…gx3yv practically all of them. If I've defined a service as requiring ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq0smdhqjvt80rt7g3mgqvwhvxs4qh8few5pyfgs6wcxap7w4vrl3sagx3yv (nprofile…x3yv) practically all of them.
If I've defined a service as requiring that X be routable, then wouldn't it be reasonable to assume that when the service sends a packet to X won't result in a EHOSTUNREACH error back? You might say "of course that's unreasonable, networks are unreliable!", and that's the real-world scenario, but in that case, what is the point of activating the service, since it can't *actually* talk to what it wants to talk to? If the service still has to be able to deal with all the vagaries of network connectivity, what was the point in delaying startup for a condition that doesn't mean anything useful?
That's even before you consider the chicken/egg problem of knowing what you need to be able to route to, and that there's both IPv4 and IPv6, and... so on and so on.
If I've defined a service as requiring that X be routable, then wouldn't it be reasonable to assume that when the service sends a packet to X won't result in a EHOSTUNREACH error back? You might say "of course that's unreasonable, networks are unreliable!", and that's the real-world scenario, but in that case, what is the point of activating the service, since it can't *actually* talk to what it wants to talk to? If the service still has to be able to deal with all the vagaries of network connectivity, what was the point in delaying startup for a condition that doesn't mean anything useful?
That's even before you consider the chicken/egg problem of knowing what you need to be able to route to, and that there's both IPv4 and IPv6, and... so on and so on.