Ask HN: What “missing” technical solution(s) do you wish existed?

Lucky you. :)

This isn't a simple problem and I don't know of any one size fits all solution for this. From what I could tell, every company comes up with its own asset pipeline that fits with their art, code, test and release processes.

I came up with a half assed solution myself back when I was still working in games. We had a separate build server just for assets. It ran a script every hour that pulled down both the code and art repos and watched for changes in certain folders. The shaders, 3d models and textures were linked via naming conventions. Through those naming conventions, the system always knew where to find all of the relevant pieces of any given individual 3d asset (in theory, anyway). It would then create the assets and check them into a separate SVN repo. This system worked ok, but it had a number of problems.

One problem was the naming conventions. The artists didn't much pay attention to file names, so any new asset they created would inevitably not get built because it didn't adhere to the conventions. We thought about replacing the naming conventions with a json file describing every 3d asset, where their shaders were, where their 3d models were, any special settings, where they should be saved, etc. but that would have required either a GUI application to help manage it all or a coder whose job was to manage the data files. The former would have taken time and the latter wasn't much better than what we were doing already. We still needed a coder whose job it was to fix asset build issues, which would pop up on a regular basis.

Another issue we had was build revisions. Game builds are complicated enough and we added the additional complexity of having to specify a branch name and version number for the assets used. It doesn't seem like it would be an issue, except when you have parallel art work going on in parallel branches along with parallel dev work going on in parallel branches things break. In retrospect, we should have put our foot down and said there is only one official asset branch and all dev builds will use the latest version of that branch, but we didn't.

Sorry for the essay, but I hope it was of some use to you. If you ever come up with a universal asset pipeline, sell that sucker! :)

Facebook knows what movies I like and interests I have, Spotify knows what songs I listen to, Amazon knows what books I like to read. All of these pieces of data are currently silo'd and controlled by private corporations many of which can do whatever they like with that data.

I want a private encrypted datastore that does this instead. Peer to peer so nobody controls it or can kill it. And controlled by you so Government can't get access. You set up a node and contribute CPU power and disk space. Then you get a private address and key and can push small pieces of metadata to it. This data is mirrored and very redundant so it won't disappear if some nodes go offline.

Then any site can integrate with this store. People will build libraries to write to it with various languages and others will build websites which make it easy for the layman to store and get data from it. People could create online "metadata banks" so that less technical people don't have to run their own node. Integrating with this datastore will eventually be as easy as integrating with current oauth services.

Having one global system not controlled by anyone also means there's now a standardized way for any service to request access to your data. They don't have to specifically integrate with Facebook, Spotify, Bandcamp, Last.fm etc, they just have one integration point and you can choose what data you want to share with them.

And in theory it will live on forever so as future services grow and die your data doesn't die with it.