Hostyoself: Server in a browser – host from your computer, your phone, etc.
github.com
github.com
Using these technologies instead of OP centralized proposition would improve reliability, scalability, security and sustainability : currently hostyoself.com returns a 502 bad gateway.
https://web.archive.org/web/20090618010520/http://unite.oper...
Introduction: https://web.archive.org/web/20090618160336/http://dev.opera....
Developer's primer: https://web.archive.org/web/20090618170044/http://dev.opera....
(Links taken from Czech wiki article, https://cs.wikipedia.org/wiki/Opera_Unite ) (I've never been fan of Opera but this project seemed great and so ahead of it's time. In retrospect I regret my antipathy prevented me to even try it.)
One of the facets was like Facebook's wall, they called it the "fridge door" IIRC, your friends could leave messages p2p and you could open directories really easily to share with anyone who had the right credentials (your "friends"). It really did pop out the middlemen -- share files direct from your computer by giving someone a link (like you would with Dropbox, but peer to peer); message people like on Facebook, but p2p ... some of that might be anticipation of developments rather than the actual product as set. It makes a lot of sense to me.
"In a nutshell, Opera Unite is a collaborative technology that uses a compact server inside the Opera desktop browser to share data and services. You can write applications — in the form of Opera Unite Services — that use this server to serve content to other Web users."
i think i'll have to agree. getting 502 here.
I don't see how you can suitably solve the ops of federation because you require consumers to administer servers. The hope with P2P is that you can make ops relatively simpler; you remove servers, run the business logic client-side, and build against a distributed CDN. The supernodes will require administration, but, because they're dumb/unopinionated services, they are able to support a variety of applications.
By extension of that argument you could argue that no server is a true server:
The fact that it's not a server in the _X_, but a client to a [_Y_ in [Database, DNS, Router, Caching Server, Search Server, REST API, etc]]_ on the _Z_ makes it less of a server in the _X_.
Maybe we should stop using the word "server" and use "client graph", or just continue accepting that there are different layers in a system.
No, it couldn’t. For example, I could say that nginx is a server on my computer, and it would be true because it’s running on my computer and is accepting connections from clients, regardless of whether it’s a client to some other service. My browser isn’t.
Why stop using the word ”server”? Just stop watering it down and the meaning will be perfectly clear.
E.g. Mongrel2 works that way.
It has the advantage that your reverse proxy does not need configuration changes to know how many processes are available - it only knows which backend servers have connected and not time out. Some such designs will also explicitly have the server do an RPC in to the frontend proxy requesting a request; doing that then also has the advantage that the backends effectively rate-limit themselves by placing themselves in the ready queue when they have capacity, and all you need to know to see if you need more backend capacity is to monitor how deep the ready queue is.
Sounds like a server, just using a different network configuration than you're used to, namely WebSocket listening in a browser's JS environment instead of raw TCP listening in a non-browser environment.
Pub-Sub depends on the specific implementation. But anything with an open network socket listening for incoming connections I'd call the server, and anything making outbound connections I'd call the client. In some implementations only the broker is the server. In others every node is a server as they're all listening for multicast discovery messages.
Who is responsible for my actions?
(If its anyone besides me it sucks)
IMHO, if the application is waiting for request to be initiated by a client, and then fulfills the request to the client, it's a server. The networking topology is really something totally different...
> Does this use AI or blockchain? Sure, why not.
They won the Internet!
Also - trains!
>What's the largest file I can host using this? ¯\_(ツ)_/¯
>Should I use this to host a website? Dear god yes.
>Does this use AI or blockchain? Sure, why not.
<3
Right now we're focused entirely on personal websites, because we believe the majority of those can actually easily be hosted on a phone (eg. How many people actually view your LinkedIn page every day? A single Facebook page doesn't require a datacenter. Etc).
We're limited to single static pages with images right now but better support for multiple pages and server code with SQLite is coming. More template types, for example stores, are coming as well.
Let us know what you think!
https://www.zdnet.com/article/opera-reinvents-the-web-will-a...
IMHO, the thing that killed Unite (or Alien, as the project was called internally at Opera) was the lack of a killer feature/app that could show off the technology to end users. Too much focus on technology, and way to little focus on apps. It kinda reminds me of Google Wave in many ways.
(At an internal hackaton in Opera, me and some colleagues built a rc-car controlled trough Opera Unite with a webcam and custom javascript plugin to control a servos directly from the browser. We also ended up building a picture frame powered by Opera Unite, and got to present it at a stand at MWC Barcelona. Fun times!)
Good times
- https://beakerbrowser.com - P2P Web in the browser (Opera Unite Redux)
- http://localhost.run & inlets - ngrok with feathers and a monocle
That's not to say they couldn't use the same approach to legally questionably or illegal content: If they have a proper complaint or takedown request, they stop forwarding to that content host.
The drag and drop interface isn't to upload the content to be hosted like a traditional server (what's the point then?) It looks like (without digging through code) it's so they can parse the file-structure and generate the URIs to forward requests.
I haven't looked at the code either. But the hosting seems to be handled in JavaScript. There are no required clients (though there does seem to be an optional one); this is all completed in the browser.
So you're not "uploading" content, you're providing the content to the client-side application so it can be shared through that same client-side solution.
you <-> hostyoself <-> someone else
where all data goes through hostyoself. This is analogous to ngrok, but at file-system level rather than TCP.
This project, like many areas in technology (especially new or cutting-edge), are not well addressed in laws, regulations, or legal frameworks. The courts of the world have not provided much clarity either, but certainly have not provided any clarity on this particular project.
You did not reference your view in relation to a particular country or legal authority, but the site is hosted in the U.S. so that is the most relevant here.
The content is not hosted by hostyoself.com, it's hosted by the systems owned by the content sharer. The legal landscape has certainly shifted providing less coverage for user-generated (or uploaded) content but there are still some protections in place for solutions that do in fact host user content. But again, that's not the case here.
hostyoself.com is simply forwarding requests to the relevant destination. Not unlikely any other traffic routing or forwarding technology. In fact, the proxy comparison is particularly apt, and a solid defense.
Of course none of this absolves hostyoself.com from complete inaction. I could certainly see them compelled to cease forwarding requests to some destinations. But I do not see a clear path for hostyoself.com to be liable for the content a particular user is hosting. The user in question is the one in possession and performing the hosting/share of the content.
Of course... the courts are the ones who would decide in such a case.
It's cute. Basically transient sharing of content from any device with a browser that supports websockets without needing a separate client.
The host ISP, the hostyoself.com ISP, the various routers, firewalls, networks between the two, and all the same for the end-user, any proxy servers on the path, etc. A lot of entities are hosting/enabling access to the content.
> Yep! Welcome to the joys of Javascript.
Although it (re-)sends file for every request, the file content must be identical. So the relay server may just cache the file.
Once you do that, it becomes more like a traditional static file hosting w/ on-demand file uploading via browser.
It would be interesting to see something using WASM to run a web server in the browser. And some kind of decentralized replacement of DNS gateways for host resolution.
You could possibly get one going on top of something like this: https://browsix.org/
Hopefully no one uses this for anything critical.
uh... okay?
>They won the Internet!
I thought this place was supposed to be better than that.