What are your goals with TFC?
Time will tell. Currently it’s in maintenance only.
How can it be extremely important in the grand scheme of things?
The remote exploitation of endpoints will become a tool of first resort for LEAs due to the deployment cost of exploits being negligible compared to the sunk cost of their development so over time the project (or at least the architecture) will become quite a bit more important.
allow for many identities per physical node
It’s currently not possible to do this but there’s no technical requirement. “Multiple identities” might not even be necessary once Tor Project implements prop224 basic authentication so you can appear selectively online. But if there’s a use case for it, it wouldn’t be impossible to add multiple identities. But new features will have to wait, I’m focusing on my studies for the time being.
I could imagine something like this as an even more secure alternative to SecureDrop, perhaps.
Sure, journalists could use TFC to establish secure anonymous links with sources. Both endpoints need to be powered on continuously to allow asynchronous communication. However, purchasing TFC-related hardware etc. isn’t necessarily what a non-technical whistleblower would want, and ordering the components etc. might leave a bigger paper trail than throwing Tails onto an old thumb drive and disposing of the thumb drive and an old laptop after making the leak via public wifi hotspot. So the OPSEC is quite complicated. IMO TFC works better in closed communication of political dissidents etc.
What are the technical limitations on message size?
The size of RAM is the only limiter for individual messages. Larger text should be sent as file (as it’s faster and has less parsing overhead on receiving end). If traffic masking mode is used by the sender, even files are sent as individual message-like packets. Traffic masking is very slow for sending large files, but the idea is you’re sending packets at constant rate anyway, so sending file data is more useful than sending noise data. Also, sending a file has smaller priority than messages so the file transmission will take place when you’re not chatting.
I ask in thinking about sending files over TFC – perhaps ones too large to fit into RAM.
TFC uses compression for files and larger messages so AFAIK the entire compressed data needs to fit in RAM. Files larger than the RAM probably shouldn’t be sent over TFC anyway, as that will must likely unnecessarily tax the Tor network. But it can be done by splitting the compressed file in multiple parts (separate compression programs have better support for decompressing several parts). It’s also a bad idea in general. At the default speed of 19200 bauds, sending a 1GB file over data diode takes more than 6 days.
Another issue is the Reed-Solomon erasure code that adds a lot of computational overhead for large amounts of data. So you can stretch these limits by disabling error correction, and/or by increasing the serial interface baudrate, or by tweaking your own fiber-optic data diode. But since the isolation mechanism breaks if you try to forward a file by moving it manually from Destination to Source (never do that!), TFC will never be practical as a file sharing tool. However, a journalist/protester uploading a photo or small video from conflict zone by connecting the camera only to Source Computer, is something that can be done.
