Automap has been implemented only for Standard mode, leaving other options out, but unlike Originate-Only (you don't need ports open for incoming connections) and Zero-Hop (no exposure to the Internet at all) there is no point in omitting Consume-Only where it's desirable for you to get a better integration in the network, exposing yourself to other Nodes (with your descriptor) and accepting their inceptions, similarly to Standard mode.
We may be able to easily reuse code designed for the implemented mode because I don't see now a reason why it would differ from parameters given by Consume-Only's Neighborhood mode setting.
Inspect if the change involves more than just the supposed easy modification in actor_system_factory.rs (but I think the code to communicate with Dispatcher about a descriptor yet unfinalized or finalized could work in any case)
New note:
Consume-only does not require to operate behind a punched router all the time. We should also give a possibility to run Consume-Only as if it were partly Originate-only...without forwarded ports. But there is still difference between Consume-only and Originate-only in the way of allowing to serve routing and exit services for other Nodes.
Another note, from a Sunday meeting:
The consume-only setting is qualitatively different from the zero-hop, originate-only, and standard settings; perhaps it should be specified separately as well, so that a Node could be classified as either consume-only and standard (punched) or consume-only and originate-only (unpunched). This is a significantly larger proposition and probably should be given its own card. If you play this card (make consume-only always punched), consider creating another card based on the knowledge you gain here to allow consume-only to be either punched or unpunched.
This card won't be ready to play until we add the capability for Consume-Only mode to operate behind a punched firewall. As of September 2023, only Standard mode can operate behind a punched firewall.
Automap has been implemented only for Standard mode, leaving other options out, but unlike Originate-Only (you don't need ports open for incoming connections) and Zero-Hop (no exposure to the Internet at all) there is no point in omitting Consume-Only where it's desirable for you to get a better integration in the network, exposing yourself to other Nodes (with your descriptor) and accepting their inceptions, similarly to Standard mode.
We may be able to easily reuse code designed for the implemented mode because I don't see now a reason why it would differ from parameters given by Consume-Only's Neighborhood mode setting. Inspect if the change involves more than just the supposed easy modification in actor_system_factory.rs (but I think the code to communicate with Dispatcher about a descriptor yet unfinalized or finalized could work in any case)
New note: Consume-only does not require to operate behind a punched router all the time. We should also give a possibility to run Consume-Only as if it were partly Originate-only...without forwarded ports. But there is still difference between Consume-only and Originate-only in the way of allowing to serve routing and exit services for other Nodes.
Another note, from a Sunday meeting: The
consume-only
setting is qualitatively different from thezero-hop
,originate-only
, andstandard
settings; perhaps it should be specified separately as well, so that a Node could be classified as eitherconsume-only
andstandard
(punched) orconsume-only
andoriginate-only
(unpunched). This is a significantly larger proposition and probably should be given its own card. If you play this card (makeconsume-only
always punched), consider creating another card based on the knowledge you gain here to allowconsume-only
to be either punched or unpunched.