Oh, so, I recently had opportunity to play around with this some, a bit over the past week. My initial questions were along the lines of:
1. What's the point? In end-to-end encryption situations usually the concern is around data storage (perhaps), but for just sending messages typically TLS is enough (or seems it, anyway, from my perspective as a non-security engineer)
2. The codebase seems to have separate C, Rust, and Elixir versions. Are they interchangeable, or do they serve different purposes?
Of these I only have rough answers. For the first, it seems like this solves the problem where, say, a single TLS connection isn't enough to get the data all the way to where it's needed (perhaps you need to go over bluetooth, or do multiple steps of HTTP, etc).
And for the second, well, I'm not sure. I think the C implementation might be equivalent, and be being replaced by the Rust one?
> 1. What's the point? In end-to-end encryption situations usually the concern is around data storage (perhaps), but for just sending messages typically TLS is enough (or seems it, anyway, from my perspective as a non-security engineer)
One use case I've used e2e for is password storage.
Assuming something like:
Browser -> nginx -> Web API -> Auth Service -> DB
This is a pretty common way to set up something like password auth, but a cleartext password will be exposed to nginx and your web api, for no reason, if you just use TLS. It's not uncommon for passwords to end up in request logs or that sort of thing in a system like this.
You could use ZKP, which gets you slightly stronger guarantees than e2e, but imo e2e is a really good sweet spot for solving this - the plaintext password will only be decrypted within a single function (the one that hashes it) in your secret server.
1. The protections of TLS are constrained by the length and duration of the underlying TCP connection. If an application's data flow involves two or more TCP connections then TLS can't guarantee end-to-end data integrity and authenticity.
If an application involves communication between entities that are not online at the same time or if the data flow involves multiple transport protocols like the first hop is bluetooth and the second hop in TCP etc. - In all these cases TLS and other transport layer solutions cannot keep an applications data safe from forgery and tampering.
Turns out application entities are rarely connected by a simple point-to-point TCP connections - even the simplest web app these days is at least - on tcp hop to a load balancer, second tcp connection hop to an application web server. For example, in a different guide, we show how application data could remain end-to-end protected while traveling from Alice to a Cloud Service to Kafka to Bob https://github.com/ockam-network/ockam/tree/develop/document...
2. Our long term plan is to have Ockam libraries available in many languages. We started our development in C and Elixir and later added Rust.
Elixir - because it's easy to scale concurrent messaging systems on the Erlang BEAM virtual machine (see RabbitMQ, WhatsApp, Discord and many other messaging systems that have achieved scale with Erlang BEAM).
C - because we want to support embedded environments along with server environments. However, a few months into developing with C, our team discovered Rust and got very excited about how memory safety features of Rust eliminate a large class of security bugs. It is much easier to create performant yet loosely coupled abstractions in Rust - this makes it possible for us to keep our library modular and pluggable. Rust tooling is also a lot better than C so we've moved development focus from C to Rust.
Later we plan to wrap the Rust library in FFI wrappers and expose it in other languages (including C). The Ockam Elixir library already uses our Rust crates for various cryptographic features.
Can this library help me if I have existing sensors I'd like to connect to securely? E.g. could I somehow proxy their requests to our remote backend via some local application?
That's an awesome question! Yes, any arbitrary protocol can be tunneled through an Ockam SecureChannel. So if you have a device that produces readings as some binary structure or JSON or some other encoding ... a secure channel can deliver that data end-to-end protected to your backend application. You can even tunnel high-level protocols through a secure channel, we recently tried tunneling SSH through Ockam to create secure remote access to a machine that is behind a NAT .. and it worked like a charm.
To make this simple and transparent, we're building a feature called Transport Inlets & Outlets. With that you can easy create a proxy (either on the same device if it has an OS or in a nearby device) without modifying your original device application - the code of your sensor. There is an open PR on TCP Inlets & Outlets (portals), if you're interested: https://github.com/ockam-network/ockam/pull/1756
Yeah, a big benefit of SQLite is the fact that it's embeddable, and easily can be communicated with from any language that can FFI out to C (which is to say, essentially any language)
Not OP but here’s my personal opinion (and I’m sure many may disagree):
There’s a bunch of parts of learning a language (a few more for Chinese character languages like Japanese) and learning one often doesn’t help you that much with the others, which most people don’t realize:
- recognizing individual kanji characters
- recognizing words formed via combinations of kanji
- reading passages in context
- writing characters
- writing passages
- understanding grammar rules
- forming sounds naturally (people who can speak sound unintelligible because of bad accent, this is not the same skill as speaking - more muscle memory)
- speaking (does not actually require understanding grammar, nor sounding reasonable!)
- listening and understanding verbal language...
- without context
- in a casual context
- in a formal context
- with unspoken, understood context (this and above two require understanding culture)
- domain specific vocabulary (everyday speech is totally different than business, and different from speech with a lot of slang)
- knowing socially appropriate things to say or do based on unspoken context
- and more I probably missed
Learning all of the above is a project that people with decades of study can’t necessarily do all well [1] - so first pick what you want to be able to achieve and focus on that, and also acknowledge that learning a language is going to be a daily practice for the next several years of your life. If you don’t want that, then time spent learning a language will probably be a waste IMO (unless you’re just doing it for a general sense of Japanese language and culture - Duolingo is probably good for that), and I’d advise you to spend your time doing something else.
For me I wanted to be able to speak in casual conversations and everything else is secondary. That said reading passages is useful for understanding how specific grammar and vocabulary is used in context, so that was my second priority. Working in Japanese companies is legendarily terrible so I never had an interest in professional or very formal Japanese (just enough to understand formalities spoken to me when I go to stores or talk with reps at companies).
I’m currently at an intermediate level after ~1.5 years of regular study - good enough for most common social contexts, not good enough for business Japanese or niche topics. Someone deeper than me will certainly have different opinions as well.
- The first ~6 months, I liked the Pimsleur series but your mileage may vary. It’s old school mp3s (used to be cassettes) that teach you not by explaining rules but by giving you scenarios and having you use grammar rules and learn by inferring patterns, responding under time pressure (an mp3 can’t wait for you - this is important!). You will not have a formal understanding of the language but it can get you to saying things pretty quickly, and gets you over your fear of sounding dumb in a foreign language quickly since you’re speaking from the beginning. You learn some basic vocabulary and (sometimes overly formal) grammar, which will make more sense when you do formal study concurrently or afterward. It’s all audio so I just listened and spoke responses aloud to it during my commutes (by train, not caring that I look like a crazy person) and otherwise didn’t change my day to day life.
- WaniKani is great for learning to read individual Kanji and build vocabulary via spaced repetition (not the same as reading passages), worth the cost (every year they do a $100 off sale for lifetime fyi), though they play fast and loose with the meaning and composition of radicals so be aware of that - also its a fixed order, so if you take classes at the same time it will be out of sync with that. The open-source Tsurukame iOS app for it is phenomenal and I use it all the time on trains.
- Skritter is good for learning to write Kanji via spaced repetition (that’s a totally different skill than reading!), but to be honest you don’t need to really learn to write - predictive keyboards are enough for most people to survive, you rarely need to write anything down nowadays. I started using it more after enrolling in classes, since Kanji recognition was a core part of that. Their app is tolerable but not great - I bug them constantly to improve their iPad/Apple Pencil support, the closest digital thing to really writing on paper and pen.
- Bunpro teaches grammar points via spaced repetition, it’s pretty decent. The app is not very good.
- Learning from large group classes is good for some listening practice and learning grammar rules in general, but not that great for speaking practice because there’s usually too many other students to get that much opportunity to speak. You will learn what you’re doing wrong, but you’ll need to put concepts in practice much more outside of class.
- Learning by speaking to classmates in said classes... is not very optimal, since they don’t know what’s right or what sounds right either. Do it for your social curiosity or motivation, not for true language practice IMO.
- Learning from a small class or 1:1 will give you higher quality speaking practice - you can find pretty cheap teachers on services like iTalki. For getting grammar and usage right, I’d recommend real teachers vs random people on HelloTalk since the average person can’t explain grammar points well, but for getting to know someone on a non-professional basis/cultural learnings, the random person can be better (but if you have the option to esp once COVID blows over, IRL friends are the best).
- Getting a job in Japan can get you a decent amount of practice, though in a particular domain - probably formal, maybe repetitive
- Getting a significant other will give you a lot of practice in the specific domain of day to day conversation, but you run the risk of adopting the sound of the SO (guy sounding like a girl, in a very gender-segregated society like Japan, makes you sound funny lol)
- Immersion is not really useful until you can at least tread water so don’t think you need to move to Japan to learn - but like I said practice is important so maybe after 6-12 months of study it’s probably worth it if your life is flexible enough to make that happen.
- trying to understand movies/anime is hard to do until your listening skills are pretty decent, especially since they usually use a lot of niche vocabulary and grammar (talking like a samurai) not common in day to day life. You can try but I found that a steep learning curve for beginners. But you can find a bunch of well-transcribed stuff at FluentU and Animelon.
This covered a lot of what I was planning to cover.
+1 on figuring out your goals. A while ago I read an article about this as well as other parts of learning a language but I can’t find it anymore.
I also want to mention that there are heaps of apps, websites and resources available for learning Japanese. (Of course, they aren’t a substitute for actually speaking/reading/whatever it is that you aim to do.) Tofugu has a regular series covering these apps: https://www.tofugu.com/japanese/japanese-learning-resources-...
There are actually a number of alternatives to WaniKani: kanji garden, kanshudo, kanji koohii and Anki + Remembering the Kanji deck + 5k most common words deck. I think the main benefit of WaniKani over these others is the API — e.g. adjacent apps like Satori Reader can hide furigana based on what you’ve already learnt. I think both the WaniKani and kanji koohii forums are good places to find more help.
subs2srs for Anki and delvin language are similar to FluentU.
If you want to improve your pronunciation look up Dōgen on YouTube or try the Waseda speaking with fluency course.
Sounds like much more work than implementing a wasm vm+runtime. Besides, isn’t it owned by a company who is notoriously litigious against reimplementations?
I like my RPGs crunchy enough to not be a barrier to role playing or abstract enough to not be a barrier to role playing. I feel like I've never been limited in what I can do or what I can create in GURPS. Games like D&D are the worst of both worlds for me. Not abstract enough to do what you want, and not crunchy enough to have rules for all you want to do. To me D&D is more like playing a board game than a role playing game.
You could look into Pathfinder, it's very crunchy with lots of options so it should fit.
On the other hand, how you experience D&D depends heavily on the GM. If social solutions to problems are not rewarded, players may feel like playing a board game. Same for GMs that railroad the story too much.
I think it’s just pref/user_pref and such. Despite the name it is not a js file and is not parsed like one. I think the file extension is entirely vestigial.
But still, there's no complete list of these and only some of them are properly documented. I've tried to look up some prefs about half a year ago and couldn't find it anywhere. There's just a wiki that mentions some of them and on various blogs you can find a mention of what something does here and there, but that's about it.
1. What's the point? In end-to-end encryption situations usually the concern is around data storage (perhaps), but for just sending messages typically TLS is enough (or seems it, anyway, from my perspective as a non-security engineer)
2. The codebase seems to have separate C, Rust, and Elixir versions. Are they interchangeable, or do they serve different purposes?
Of these I only have rough answers. For the first, it seems like this solves the problem where, say, a single TLS connection isn't enough to get the data all the way to where it's needed (perhaps you need to go over bluetooth, or do multiple steps of HTTP, etc).
And for the second, well, I'm not sure. I think the C implementation might be equivalent, and be being replaced by the Rust one?