Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Reelya]

uh, by being the backbone for the ride sharing system. The humans have the cars. People have already built working systems like this.

Maybe you should start using google before being incredulous. I was able to find two different systems in three seconds with google
http://www.newsbtc.com/2016/03/22/using-blockchain-decentralized-ride-sharing-lazooz/
https://cointelegraph.com/news/arcade-city-decentralized-blockchain-based-answer-to-uber

[wierd]

Clearly I am a curmudgeron when it comes to this whole "Mobile Infrastructure" thing, but I have to ask-- what is wrong with using a phone number?

When you have an app for everything, you will need a bazillion apps to do anything. That in and of itself is very undesirable, IMO.  I could just have a phone that can call any number.

[Reelya]

Clearly I am a curmudgeron when it comes to this whole "Mobile Infrastructure" thing, but I have to ask-- what is wrong with using a phone number?

When you have an app for everything, you will need a bazillion apps to do anything. That in and of itself is very undesirable, IMO.  I could just have a phone that can call any number.

How many people are you going to call to get a ride? Randomly call everyone in town? The whole point is to cut out the costs of having the centralized company.

[Starver]

Blockchain currency solutions have at their core the concept of solving increasingly more tedious problems to 'earn' the wealth therein, which can then be distributed accordingly.  Clearly the ultimate version would be to have the problem be "who wants to go where?", and the person who discovers/fulfils the conditions of that problem earns the credit.

And why should this even need the 'customer' to use an App, if their need is purely derived from the very process that is generating the work?  You step outside your door, and discover that someone who happens to be going your way is waiting for you, even if you hadn't yet decided your itinery yet...

In Blockchain Uber, taxis hire you!

[wierd]

Much like how there are a vast number of implementations of blockchain based cryptocurrencies, each rideshare service would not want to use the same blockchain as their competitors (because reasons), and so to connect to the various different blockchain authority trees (such as to hail a ride), one would need different apps for easy integration. (EG, "push the 'Hail ride' button, and we automagically use your phone's GPS to get a coarse location, and a nearby provider is alerted to your hail, and goes there to get you!-- But only for OUR service!")

As to answer Reelya's question-- What is the functional difference between supporting a computational infrastructure to manage the internet connectivity of the app (the app needs a central server to talk to, because it is not clairvoyant-- it needs to keep track of what ride providers are in what areas, at what times, so it can do the assignments) and keeping a call center, other than having humans involved?

If you use a robot answering service, is there really a functional difference, other than "I used an app instead of calling! Whoo!!" ? Natural language processing is very useful, and can be used to leverage several useful services automatically-- such as programatically detecting if the caller is drunk based on speech patterns.  There is also a fairly universal method of keeping track of different contacts in the phone already-- the contact list. Most phones allow you to sort it by arbitrary categorization, like "Ride services".  No need to fumble for a bunch of different apps, who may or may not all want to update before they connect to the blockchain authority-- when either a voice call or a text message with an address will suffice.

Text service being especially useful for areas with abysmally shitty cellular connectivity. SMS needs less than 1 bar of signal to send out.

[Reelya]

Blockchain currency solutions have at their core the concept of solving increasingly more tedious problems to 'earn' the wealth therein, which can then be distributed accordingly.  Clearly the ultimate version would be to have the problem be "who wants to go where?", and the person who discovers/fulfils the conditions of that problem earns the credit.

And why should this even need the 'customer' to use an App, if their need is purely derived from the very process that is generating the work?  You step outside your door, and discover that someone who happens to be going your way is waiting for you, even if you hadn't yet decided your itinery yet...

In Blockchain Uber, taxis hire you!

Well no that's not really a good description. Blockchains have at their core rewarding people for processing the transactions that make up the service. If you buy something with bitcoin, it's the miners who make the actual financial transaction exist at all. They didn't put mining in for lulz, they put it in because you can't expect people to just keep processing transactions for free. That's what the blocks that miners create are: a block of transactions that other people have requested. So yes they did earn that, because it's the miners who make the service operate.

And the cryptography is there as the validation that you're not just inserting fake blocks. Each block of transactions carries a cryptographic key that's only valid when connected to all the other blocks in the chain, that way you can validate that the transactions in your database haven't been tampered with, and by comparing it to everyone else's database, that you all agree on the contents of the ledger: by checking the hashes on each block you can make sure they all add up and that everyone else has the same hashes. The way it's done is actually a critical component of the idea behind a distributed database with no "owner".

So no, the cryptography is not just some "random puzzles" they made up for fun, it's a set of hashes that uniquely identifies the entire transaction history of the network. That's what the miners are producing when they "mine a block". Rather than being random, it's an important task that's critical to ensuring that the data is secure.

Now, people might not be aware that they're processing financial transactions for other people, and encrypting information about the transaction history, when they join a coin mining pool, but that's not really relevant. What they are in fact doing is validating the current round of transactions, regardless of what motivates them to do so.

[wierd]

Blockchain based systems for ridesharing would be useful to verify that the responding vehicle is unique, and has a positive ID-- as well as the ride hailing device, which is useful for conducting a microtransaction. It would also be useful for verifying that the GPS location of the hailer is legit, etc. (getting a valid block in the chain is accomplished once those things are verified by the crypto function, by using that data in the key hash generation) but other than that, and providing a means of authentication for automatic payment transfer (as in with a cryptocurrency), it does little to alleviate the computational burdens of tracking where ride service providers are in real time to pair them with ride hailers.

It also does little to alleviate the costs associated with all the endpoints needing to broker contacts with each other. While it is true that P2P fileshare networks have created distributed hash table type methods of finding peers, they still need a bootstrap server of some sort for peers to connect to the swarm. Many use a "Last known peer" to help distribute that, but still not useful for a "first time connect", which would still need a reliable "all else fails" contact point to broker entry into the swarm.

Also, that would require continual contact with all the peers, which would destroy the batteries of both hailers and service providers.

Externalizes are totally a thing you know.

[Max™]

As someone who briefly drove a cab (2003 Crown Vic Police Interceptor, weeeee) and remembers the crazy cash I'd start out with after a night, I did kinda wonder where the whole "paying the company" bit came in with Uber. If I was driving a cab and didn't have to push as much cash back to keep my cab I'd probably be singing the praises high and low surrounded by angels and such.

Was still great money, but mostly because I was young, had spent years using streetmaps of Louisville to run rpg sessions on, and most of all: I avoided the airport trap. Yes, generally the fare and tip from the airport is going to be nice, but sitting in that fucking queue... did it once, can say I understand it now, never did it again.

Also had a scary night where dispatch told us a cabbie had reported an attempted mugging and had not been heard back from, so at like 2 or 3 am you've got half the fucking fleet swarming the area looking for the car/them/the unfortunately vague description. We're all competing, yes, but goddammit cabbies look out for cabbies. Who does this with "random person who decided to start Ubering" when shit happens? Yes the cops will be there, and yes they were out there with us too, but it was a cabbie who spotted their car with the service light off and got the cops zeroed in on the fucker. Weirdly I don't actually know what happened, I just knew the car number and area where the last call back to dispatch came from and was maybe a mile south of there so I joined in the swarm hunting for the fucker.

[Helgoland]

That would make for an awesome movie, actually. Retired cop takes up cab driving to improve his meager pension, then his son, a junior detective, is killed by the mob - and he swears revenge.

[Reelya]

At my new work, they spend a lot of time fine-tuning this particular physics simulation in this game, by hand, and this has to be re-done whenever they change any of the related settings, so I wondered whether some sort of AI could actually optimize that sort of thing for you, they scoffed and explained "you can't optimize for fun". but isn't this just another example of people thinking that their job can't be automated?

I read somewhere that people generally agree that everyone else's jobs are doomed, but they all agree that their own jobs are safe and "couldn't possibly" be replaced with automation. Just everyone else who isn't them. They're all on a one-way trip to oblivion. Everyone except me. Which is of course contradictory.

[wierd]

I recently ran across a study from oxford, that suggested that 25-30% of all employment in the US will be replaced by either robots or software agents in the next 10 years.  It was released in 2013, so a few years old now.

While not the focus of their study, they did pointedly remind the reader that the work of their peers shows that the rate of removal of jobs is outpacing the rate of job creation, and cited their peer's work on that.

Given the rise of things like deep learning, and improvements in soft body robots, (especially when taken together, as the former provides powerful vision systems for the latter) it is only a matter of time before most jobs are more efficiently and economically staffed with robots or software agents.  This cuts both sides of the wage divide, as evidence by the huge reduction in humans seen in places like Wallstreet. (the number of humans on the trade floor is a tiny fraction of what it was 15 years ago.) I expect that trend to continue once upper management discovers they can be replaced with far more efficient software agents.



Ipsil-- while "fun" is a concept that machines are incapable of grasping, they are more than capable of grasping sales metrics. Humans tend to buy games that they find fun. The machine learning algorithm may not comprehend what fun is, but then again, it does not comprehend what an apple is either. Does not make it less capable of identifying what is and is not an apple based on other metrics.  The same is true of an AI that takes feedback from a more easily measured proxy variable, like sales.

[wierd]

I am well aware of how machine vision works Ipsil. That is why I mentioned that machine learning systems trained to identify apples, have no clue what an apple is as a concept. They only observe a collage of datapoints that fairly consistently manifest in images of apples, and then weight a decision on weather or not the image is of an apple.

The same would be true of an AI that looks for "fun"-- using sales as one of many metrics. User review scores (not professional reviews, because they are tainted by their nature), hell, even the very code used to create the game itself, could all be sources that can be mined in that respect.  Early training would require a human tutor, just like machine vision does, but once it had a good model under it, it would be off at the races.

[wierd]

Only if you have small samples, which would be prone to false positive trends.  Get enough dataset, and if there is a trend there, it will manifest.

The argument you are making is that not enough data exists.  I would counter that; there have been thousands of games made in the past 30 years, lots of market research done, etc.  All of that is potential food for such an AI.

[Reelya]

I also think the armorphous idea of "fun" can be 'metric'ed" to some degree.

What is "fun" in a game? Can fun be measured? I think it can be measured as the amount of engagement in the game. A game activity should have engagement as much as possible, and it should provide a decent range of win/loss conditions, based on how much you engage. Something is "easy" if merely engagement itself is guaranteed to win, whereas something is "hard" if you need engagement plus additional win conditions to ensure victory. Optimized fun is any state which maximizes engagement, in the sense that you feel like what you did mattered. If something doesn't require engagement at all to win, it's not a game.

e.g. if you're jumping over a pit in a side-scroller, then that's engagement, and the level of fun is dependent on things such as how quickly you jump and whether you can "glide" the controls in the air. the level of difficulty is dependent on such things as how accurate you need to be when you take off, and whether you need to be able to control the thing in the air, and if so, how sensitive it is. If you're guaranteed to make the jump no matter what, it's (not) so "fun", if you lose control for too long (e.g. the jump is too slow) that's not fun either, or if it's too difficult and fiddly then that becomes less fun as well. So you can in fact produce metrics for all those things.

e.g. something is not fun if you don't need to engage enough, or you need to engage too much to win. There should be a good sense that your options of how you engaged lead to the victory or loss condition. So in terms of this physics game, it's tuning the controls to jump a car over a ravine, and the car is a sci-fi one with some glide control from spoilers/wings. I believe we can in fact tune how "fun" that activity is via machine learning (I was using AI as the broad term, because it can really be by any means). e.g. how much is success or failure dependent on the specific controls you press. That can be tuned for directly.

[Reelya]

Yeah, and with that sort of setup, you can have co-evolution with the controls too, start with random controls but use genetic algorithms to evolve cases of "better control" meanwhile evolving the physics to make it succeed a certain percentage of the time. You can then evolve "perfect controls" but adjust how much leeway there is with that, so that "good enough" controls will get you across. You actually want to maximize the number of "just made it" or "almost made it" situations. Basically I think a lot of "fun" in twitch-based games comes down to maximizing the chance of edge cases.