Java's verbosity made us all hate type systems in the early 2000s so many of us migrated to dynamic languages such as Python, Ruby in the mid 2000s that allowed us to work fast and loose and get things done.
After about 10 years of coding in a fit of passion we ended up with huge monolithic projects written in dynamic languages that where extremely brittle.
Fortunately languages with type inference (Rust, Golang, OCaml, Scala, etc) started becoming the answer to our problems. (We also collectively decided that Microservivces were another solution to our woes though that cargo cult is being questioned).
So we have a decade of code and packages written in Python and JavaScript that work well for our use cases (Data Science, MVP web apps/services, Database integration, etc) that is hard to give up. Often because alternatives aren't available yet in the statically typed languages (Hurry up Rust!).
There is often a lot of friction to get new languages introduced. I love Rust, but I don't think I can introduce it into our Golang/NodeJS/Javascript environment anytime soon.
I don't know for certain without digging into the code but they are probably using the WebCryptoAPI and doing everything client-side to encrypt the file.
The URL that is shared contains the key for the file. You'll notice that the URL contains a fragment identifier, i.e the #foo part of http://example.com/#foo, this isn't transmitted to the server by the browser and therefore the key isn't exposed beyond who the URL is shared to.
I would get a Z-Wave daughter board and use Z-Wave devices for controlling the electronics. Z-wave devices aren't Internet connected so you only have to worry about locking down the Pi.
Apparently there's already an open source project called Home Assistant for this purpose.
We don't need another federated network. Administrators of those nodes are putting themselves into danger. What we need to develop is a purely decentralized p2p network that is resistant to censorship and eavesdropping.
No, usually there's an accept process spawning working processes and passing the connection off to it.
Erlang can have two versions of a module present in memory at a time. At the moment of a code upgrade, the processes working with existing connections continue to use the old code while newly accepted connections are passed to the version of the module that was loaded in between connection accepts.
After about 10 years of coding in a fit of passion we ended up with huge monolithic projects written in dynamic languages that where extremely brittle.
Fortunately languages with type inference (Rust, Golang, OCaml, Scala, etc) started becoming the answer to our problems. (We also collectively decided that Microservivces were another solution to our woes though that cargo cult is being questioned).
So we have a decade of code and packages written in Python and JavaScript that work well for our use cases (Data Science, MVP web apps/services, Database integration, etc) that is hard to give up. Often because alternatives aren't available yet in the statically typed languages (Hurry up Rust!).
There is often a lot of friction to get new languages introduced. I love Rust, but I don't think I can introduce it into our Golang/NodeJS/Javascript environment anytime soon.