Figure out the ethical solution to the C interop / crypto question

[alex]

Design considerations:

• C is awful
• Encouraging C interop mostly means encouraging an interop with libraries that are terrible and which will randmoly segfaults.
• Writing crypto code is scary
• Writing a TLS implementation, which is fundamentally necessary, is a lot of crypto code.
• Is it even ethical to offer people a TLS implementation which includes crypto which hasn't been audited?

[alex]

Some more thoughts: TLS is just a network protocol, no reason to be afraid of it. It's a protocol parser, not crypto.

TLS requires some crypto though, and locking out C also locks out existing implementations of this.

I could use some moral guidance from other folks :-)

[glyph]

Thought: you can't actually lock out C, you can just leave it to someone less skilled and principled than yourself to implement the integration (which everyone will use, because "interop" == "C" as it stands today on basically every operating system ever)

[alex]

So, you actually can lock out C. If bagel doesn't offer any sort of way to bind, there's really no way to shove it in. Like, if Java didn't have JNI, how could you shove it in there?

[glyph]

Java locks out C via license restrictions. Do you plan to make Bagel patent-encumbered, closed-source, or burdened with some weird novel license? If not, someone can easily fork Bagel with the ability to load shared objects; the amount of utility they could add would be significant and it would be hard to stop people from using it.

A better example of how one locks out C without odious licensing terms is JavaScript, which locks out C by having its deployment environment be widely distributed and hard for developers to control. (And even so, Node has C extensions aplenty.) A killer Bagel app for mobile agents or user-facing applications might be able to provide this property.