Mozilla's Connected Devices Innovation Process: Four Projects Move Forward

> 0pointer-branded narcissism

It is possible to avoid that crap. Older - and much saner - software still works. Just ignore the "desktops" and run the specific tools you need in a saner windowmanager of your choice.

# e16 - from my cold, dead hands

The interesting, or sad thing, is that many of us that had already commercial experience saw this coming and always stated that in the eventuality of GNU/Linux becoming successful it would be bend by corporations like any other OS that went big.

But, as usual, youngsters stated we were just naysayers.

And now GNU/Linux distributions are basically a 2nd coming of UNIX wars.

>Competitive advantage? I think you mean core competency.

Yeah, the latter.

That said, they should work on their competitive advantage too -- the fact that they are open source and pro-web which matters to a lot of users.

No. The team was repurposed, not really Firefox OS though. Have got some insider knowledge on this one.

I mean come on. Firefox OS on embedded devices, the thing could barely run on cheap smartphones.

Sounds strange to hear about Mozilla with language generally used for talking about Yahoo...

A basic problem with the "internet of things" is who gets to talk to whom. How do devices get introduced to each other?

Living units need an identity. Devices introduced into the living units need to be introduced to that identity to pair with it. Phone-based programs may also need to be paired with the living unit identity. Each pair needs a set of security restrictions.

You want to set this up so that the homeowner can look at the house webcams, but nobody else, including the webcam manufacturer, can. A unified identity and permission system, perhaps built on Persona, lets you set up such connections without every phone having to be paired with every device. Also, with a unified permission system, you can revoke permissions. You might permit a guest access to the house systems but remove that access when they leave, for example.

I think that security will be very discussed thing once IoT will be more spread. I also think that Mozilla could be first to solve it and Persona could help with it. I imagine using it for authentication of connected devices in my home.

Note that we are still at a very early stage of exploration, so anything I write might change a dozen times before there is a first official prototype.

The current prototypes of Project Link are developed in Rust and tested on a RPi. However, we have not decided of a specific hardware platform and there are even chances that this will remain cross-platform – I'm currently running prototypes on my laptop.

In the current state of things, yes, the software is designed to act as a proxy between connected devices and connected devices and your access point.

I can't speak for other projects, but we definitely intend to have an update mechanism. This is very much not finalized yet, so any suggestion you have (currently, as a detailed blog post – once we are better organized, as a RFC) would be useful.

I sure hope so, regarding Tor and Mozilla. Aside my scripts that make .onion resolution on a Linux machine work, it would be nicer to have a simple and clean interface here.

I certainly understand the hesitancy with IPFS. It is still too new. And they're still ironing out features and implementations. However, what gets me is that it's live right now, and I'm using it for quite a few things.

Right now, I'm getting some VM stuff up and running. My idea is that jor1k linux in JS can be run on IPFS.. Still playing around with it, but it seems very stable and fast.

Also, regarding your 3rd point: I've attributed many network effects to the 85/15 principle. The 15% is your tech userbase. They're the ones that drag everyone else into a platform or technology. The rest (85%) follow because the early adopters knew that it was where to go. Gmail was like this, as was Facebook, as was Firefox, as was Napster, etc. Adding in something like IPFS as a base support adds in "Cloud Storage" where nothing really existed like this before, well, aside 'cloud' meaning other peoples' servers.

Maybe I'm completely wrong. Time will certainly tell, but one thing I know, is that I am indeed impressed with what I'm seeing already.

Some of those are honestly pie in the sky, I'll admit. But still seeing a statement that's where resources would be being spent would be ideal for some of those.

With regards to Tor/I2P, It would go a long way to be able to understand that a .onion or .i2p link was clicked and to use an alternate resolver. That would also call for a mode in the browser that sanitizes all user fields and makes the browsers look all exactly the same (to maintain anonymity).

For IPFS, I'd like to see a client-side javascript that handles the peer processing of a node, as well as being able to understand a /ip[n/f]s/hash is an ipfs link. So far, we have resolution via localhost:8080 or ipfs.io/ipfs/hash resolution depending if you're running the peer program or not.

I know that IPFS is actively working on a websockets/client side js for their system, so that any browser can play along, with no noisome downloads or binaries.

And honestly, I didn't know about Servo. I've already enough on my plate, that I didn't need to know about yet another awesome project :)

Just for the reference: I'm building similar systems professionally (and have done that with most mainstream programming languages on the market), and I was probably the first one who explored async IO and eventloops in Rust (https://github.com/Matthias247/revbio - but I'm not really proud of it) - so I think I'm at least halfway qualified to talk about this.

And unfortunatly by experimenting with these things I really got the fealing that these problems don't expose the best side of Rust. Wrapping lots of types into stuff like Rc<RefCell<T>> wasn't the greatest experience, and the problem that this didn't work with trait objects back then did not increase that either (might have changed).

Message passing is a low level primitive, and it's probably a decent solution for communication between threads. However there is also a need asynchronous communication inside a thread (the eventloop thing), for which they are not really useful. Futures/Promises/Observables are great for both use cases (and imho even greater in a singlethreaded environment). These are definitly harder to implement in Rust - and if you don't believe me just check out how many good implementations are currently available in Rust vs. other languages.

How does the eventloop design in Servo look like? Wasn't that some integration with Spidermonkey?

I agree that in Rust you will spend less time on writing tests and debugging - but this applies also for a lot of other statically typed languages which bring in a better ecosystem for that task.

I thought the base protocol was quite OK, but the complexity arrives as soon as you try to integrate blockwise access and notifications. From my look on it there are quite a lot of possibilites for race conditions there (e.g. bigger data chunks changing while transfers to clients are in progress) for which you might need to implement additional functionality (e.g. making copies of that data). But then you also need to exactly track how many clients are subscribed to that data und how long you need to keep that it (you want timers, and probably more timers than in any other protocol).

I don't recall the exact thing, but there was also something that I didn't like about the message IDs which you somehow need to keep ordered and check which ID might be used at the current point of time by which peer. A correct implementation may not send something while no ID is available, but to track all of those you needed lots of memory (much more than TCP buffers), and the open source implementations I looked at all elided that detail.

Thanks, that's what I've suspected.