I have heard twitter has a phone number you can call to ask them to open a tcp connection to your box if you were smart enough to implement an RSS client using a listening socket. Or just use carrier pigeons like you said, but be sure to support RFC2549 and ensure they can haz a cheezeburger on long-haul flights.
I guess there are different kinds of requirements to implement different kinds of addons for spring (just a random guess out of nowhere...). It just happen requirements of those who want to implement a network client and requirements of those who want to implement a network server mostly overlap in this specific case: only connection setup differs... send, receive (-thread), close are shared.
If you are misrepresenting what I said because the thread is called "Lua lobby" and nothing else matters, then fine, just state it clearly and dont tempt me to answer like I do. Do I have to copy-paste my proposal to a new thread so it gets proper consideration as a "feature request" that doesnt carry network penetration risks? I promise I will make it extra-clear that people should not expect to be able to implement an RSS client using this (unless they find the phone number I was talking about earlier).
If you just didnt understand that a listen-only implementation would be useful for some use-cases (I gave examples...) but not for all use-cases (among which might be yours), then just call this "useless" as you did, I'm fine with it. And its fine too if you think your USB ports are useless because they cant work in device mode... who would use such a useless port to connect a mouse? It cannot even be used to connect 2 hosts together (without a "bridge"), that USB technology is useless!
As I said, I just fear that people who might benefit from server sockets right now would have to wait until you figure what kind of condition has to be put in the if-statement restricting use of the connect function. My implicit proposal was to comment out the export of the connect function until you resolve this political issue. Lets be clear, I value the fact that some consider the risks of unrestricted connect... while being highly "skeptical" of those who believe they can avoid publicly available information from coming in through the pipe. Big lobbies (music, movie, not your kind of lobby) have tried to control information flow and failed miserably.
If you wont implement sockets until you find a way to prevent a "loopback feeder" scenario, give up now... you cant control information once its out. Cheaters will outsmart you and feed their nasty "see-it-all" widgets by using covert communication channels such as cpu load of fake spectators if they feel doing something funky while running an unadulterated spring on player side. Or they will use NAT to outsmart your whitelist and translate your whitelisted IP to bridge with their spec spring "drone"... because yes, NAT can also be applied the other way around by "creative" people. So, dont expect whitelists to prevent the player from connecting to any IP he wants... all it can do is prevent nasty unreviewed widgets from doing some type of harm, that is: connect behind your fw or to it without your knowledge, which is a Good Thing. In the meantime, low-tech cheaters have their spec friend on the phone, so they do not even need to be smart or have 2 computers...
Dont invest too much in that barrier:
... and if you do, give us listen-only sockets while you over-engineer the barrier's retina scan. I have lots of ideas for controlling spring that I'd like to evaluate... its just too awkward to do it now without some kind of open interface...