Notes: three years of professional experience with both larger established companies (dev team > 1000 people) and small startups (dev team < 10 people)
Notes: three years of professional experience with both larger established companies (dev team > 1000 people) and small startups (dev team < 10 people)
Maybe the key to improving incentive is to bind the acts of participating in and supporting a decentralized service so that simply using it helps construct the network itself, i.e. every client is itself a federated server. The tradeoff is that the service has to be robust enough to support a certain percentage of clients being offline at any moment, and it certainly takes more effort to construct a client that includes what would normally be delegated to a server.
(I'm sure someone's already thought of/worked with this idea before, though.)
I remember hearing in a podcast that openbazaar.org tried this approach but because of unreliable clients parts of the network would be completely unaccessible. They then went with a partially decentralized solution with a few main nodes always supporting the system. I'm not sure what has changed in the design since that podcast episode though.
I'm not sure which podcast that was. Currently content is served by others that have viewed that content, but new content gets pushed to a few configurable nodes to store that content before anybody has viewed it. This allows vendors to make changes and shutdown the software immediately instead of needing to wait until somebody has viewed their change.
Except being morally objectionable and a PR disaster? No serious website would do that. I've completely stopped visiting The Pirate Bay after they put a miner there without users' consent.
The serious use case for these miners is that you have some kind of incentive for your users to mine, not just have it mine randomly in the background. I guess it works for pure donations but take a look at "Use Cases" on the front page for a couple of examples of what I mean.
That makes sense. I do appreciate that they went to the effort of putting intended use cases on their website, and I wouldn't mind explicitly encountering some of them (I would gladly mine some cryptocurrency to help support video creators I enjoy rather than watching or seeing ads). I just worry that "morally objectionable" and "PR disaster" aren't enough to stop JS miners from being used without the user's consent on sites--to me it feels somewhat comparable to ad tracking behavior.
Okay I'll bite. How is your choice of device the dev's responsibility?
I mean it's not like it'd make sense to flame blizzard or bethesda because you can't play as long as you'd like on a laptop/mobile.
You use the proper device for the proper use, and this way you just get an additional option to trade value with the site owner. You're free not to mine in the same way you're free to get a paid account if you don't like ads.
That's not "the big problem" in my opinion. I don't even know if I would consider it a problem at all. If I want to drain my computer's battery and get something for it that's my choice. As I said in another comment, the actual big problem is rogue sites putting this crap without user initialization or even informing them.
Which solution are you using? Fellow contacts user here (monthlies), I'm looking at the side of my B&L bottle and it says to use nothing besides the solution.
Well hey, would you look at that. Exactly what I'm trying to do!
Heh I was shooting for the REST API because I figured there's nothing that doesn't communicate through it today. I'll have to check into it more, especially if I decide to do dedicated stuffs down the line. I am a fan of the multiple strips thing.
The bridge code is at https://github.com/mjg59/ulfire but doesn't have the Bluetooth code since I haven't got it working reliably yet (the machine I'm testing with has an ancient version of Bluez, and I need to upgrade that before doing more testing). I'll push that in the near future. It's pretty board specific though, I've found at least 6 different Bluetooth LE protocols for lighting so far. The easiest way to do it for testing is to just call out to gatttool in the callbacks.
I'm not a huge fan of using Bluetooth for this application, but you've done some great work there .. I'll have to look into your implementation of the Hue API, maybe we could use it on the MagicShifter (which uses WiFi instead of BT)... ?
Remote: Yes
Willing to relocate: Possibly, in the future
Technologies: React/Redux, HTML/CSS/JS, Python, AWS, linux & shell work
Resume/CV: available on request, drop me an email
Email: kienan (at) kienankb.com
Github: https://github.com/kienankb
Notes: three years of professional experience with both larger established companies (dev team > 1000 people) and small startups (dev team < 10 people)