d1plo1d

For reference I have over a decade of JavaScript experience in industry and my async Rust rewrite of a large JS project was *more* concise then the heavily refactored and polished NodeJS version (a language I consider more concise then most). If you are having to copy and paste excessively in Rust that is an issue but it is not necessarily intrinsic to the language.

For what it's worth traits largely prevented copy and paste and where traits fail there are macros. The classic inheritance example you link to is a tiny percentage of my code and an orders of magnitude smaller time sink when compared to the code maintenance problems I faced in other languages.

Very true. I'm checks cloc 14,000 lines into a personal project and I have yet to feel any need to use `dyn` (virtual dispatching for non-Rust folks).

I really hope they change the name. Citizenlab.ca is quite well established and doing important work.

Yeah, dynamic DNS but for an IPV6 address was what I was meaning. Very interesting.

Wow, am I getting this right? It handles NAT traversal for you behind the IPV6 address for free??

Sure, right now I'm using a nodejs WebRTC datachannels implementation but there's an up and coming rust implementation which I'm quite excited to try:

- NodeJS DataChannels: https://github.com/node-webrtc/node-webrtc

- Rust DataChannels: https://github.com/lerouxrgd/datachannel-rs

I tunnel everything through webRTC. It's a bit exotic but it gets you a direct bidirectional data connection to the self hosted device. You can put all users' self hosted content through a single domain name & SSL cert or you could have subdomains automatically provisioned for each device.

I'm using this WebRTC method for 3D printers at https://tegapp.io

I look forward to the day everyone can have IPV6. For now many of us still have to deal with NAT sadly - especially if we're open sourcing our software for users to deploy on any network.

Hello fellow 3D print curmudgeon,

The Makerbot Automated Build Platform was terrible in many ways so an eternity ago I forked ReplicatorG and got it printing continuously from a queue.

Once I did that I really appreciated being able to leave my printer running all day and have it produce bins full of parts. I especially appreciated being able to add prints to the queue while iterating on my CAD designs.

So, shameless plug: Inspired by that experience with the Makerbot I've been writing an entirely new print conveyor-ready print queue for the raspberry pi. Coming this fall at https://tegapp.io/

Ok, 3rd edit. The promises are awaited in sequence but since they are both started before the first await they are run in parallel.

Your question about Rust futures makes a ton more sense now. This only works because a promise is self-executing / not inert like a Rust Future. Thank you kind stranger! Your async-foo is strong ^_^

Hey @varbhat, I think perhaps the downvotes are due to some AFAIK incorrect assertions in your comment.

Rust allocations are I believe closer to C then C++ and Linus has already supported Rust: https://www.theregister.com/2020/07/13/rust_code_in_linux_ke...

So basically the question as it's asked doesn't make sense as I understand Rust and if someone took that to be intentional could be interpreted as language FUD (which could then deserve a down vote). An update to prevent the spread of misinformation about the language would be cool.

PS. I've only been using Rust on the daily for the last 8 months so I am by no means an expert. If there is a reason for your assertions that I'm missing I'd like to know. Thnx!

I could be wrong but I interpreted the down votes as about incorrectly equating of Rust and C++ allocations. There are a few replies that address this better then I can (I'm limited here in that I grok Rust but not C++) but I believe the comment would have been more correct to draw similarities between C and Rust explicit allocation then C++ and Rust.

Hence why Linus is allowing Rust for certain Kernel aspects whereas he has previously rejected C++: https://www.theregister.com/2020/07/13/rust_code_in_linux_ke...

I expect that will execute sequentially though as opposed to the solution above it.

I'm in a similar boat with regards to launching a new, unknown product in the snap store. As an interim solution I'm planning to ask users to do use the beta flag: `snap install my-app --beta` which gets me around the secure sandbox requirements.

Very cool to see more people experimenting in this area. I've similarly implemented GraphQL over WebRTC for https://tegapp.io/ and had great initial success 3D printing over data channels.

One thing I didn't immediately see in this code (excuse me if I just missed it - this was a quick read through) is a chunking mechanism to limit data channel messages to their 2^16 byte maximum. If your looking for a drop in solution saltryrtc has something you might be able to use: https://github.com/saltyrtc/chunked-dc-js

GRPC and similarly GraphQL over WebRTC gets you a long ways towards controlling local servers over the net however the problem of how to handle signalling in a way that works both online and offline is still a big hurdle. Personally, I'm pretty excited to see where these WebRTC servers can go with DAT and IPFS decentralized signalling solutions.

Thanks again for sharing. Great project!

I'm always interested in feedback. Sounds worth it even for that tbh. Cheers!

Hi Patrick, I've been prototyping end-to-end encrypted 3D printing over webRTC. Would decentralizing remote 3D printing fall under the banner of fixing the internet?

As someone newer to Rust who has been using error-chain because it was what I found at the time I'd be curious to hear what your preferred solution to errors in modern rust is.

Just to note that the session can still be thoroughly hijacked through malicious javascript on a page protected by HTTPOnly cookies in that the malicious code can make AJAX requests in the users browser to your domain and the HTTPOnly cookies will automatically authorize them. The difference of HTTPOnly cookies vs Local Storage is that the hijacked session is limited to the users browser/computer in the HTTPOnly scenario and in the Local Storage scenario the token can be downloaded and used later by the attacker (this is somewhat mitigated by things like JWT expirations).

So that is similar to an XSS in that it gains you the ability to inject arbitrary JS in to the page. That scenario is covered in the article with as I understood it the TL;DR being that lifting tokens is less practical in practice then using the browser directly to send malicious requests. The result of either attack are also similar in that as soon as your injecting JS into the page you've gained access to the users session.

Could you explain your reasoning behind the two tokens approach? I'm guessing the HTTPOnly cookie is there to prevent token stealing (low risk as described in the article) and add defence in depth against local storage/cookie zero days?

Not terribly related but I am starting to see this as a pattern on the internet:

When I bring up the latest and greatest (eg. Flow) it doesn't actually work on Windows because Windows is as I see it an after-thought for a lot of the Open Source world.

But I've brought up this exact problem (the lag in tooling) to .Net/Windows devs before and they've told me I'm wrong and that they've got all the latest and greatest dev tooling like everyone else.

Yup, I was definitely wrong on that one. Sorry about that.

Thank you for correcting me.

Personally, I'm more excited about Flow because it introduces a modern type system into ES6/ESNext without me having to sacrifice Babel.

With regards to types: TypeScript has only recently added support for any kind of Algebraic Data Types whereas Flow was built upon Unions and Intersections from day one. That to me speaks to their priorities.

Oh.. [sad_panda.jpg]

I'm still trying to figure this out but isn't it sending the ECDH of the private key which would be much longer then what the average user is going to use as a password (eg. I don't know, 1024 bit or something) and therefore more secure then sending a hashed password?

Edit: And then you (maybe?) use your password to encrypt the private key locally.. maybe? That's a total guess. That's what I'd do :P

How is this relevant to Hacker News?

Edit: just FF'd to the 3d cube bit.. nm. We can't do that without WebGL. That's what I get for not watching the entire video.

Not sure what your getting at. The Wayland demo looks like it could be completely recreated with existing CSS3 3D transformations.

Here's a similar example in a browser using HTML and CSS3. These transforms can be used on anything you can fit in a DOM element: https://www.webkit.org/blog-files/3d-transforms/morphing-cub...

First Kendo impression: Unnecessarily verbose docs, completely bloated @ 1.4MB of js minified, super-monolithic, probably a royal pain to use with angular or ember.

No way in hell I'm using this.

w00t!