A better solution would be to integrate propositions like dweb[1] in browsers then simply use socket listening. Without socket listening, using WebRTC to create direct connections is also a solution. UPnP and ICE can help to configure routers and/or bypass their restrictions.
Using these technologies instead of OP centralized proposition would improve reliability, scalability, security and sustainability : currently hostyoself.com returns a 502 bad gateway.
I find myself saying this a lot recently: Opera Unite, integrated a p2p web server for social messaging and file sharing. Wish it had taken hold, that looked like the stepping stone to federated social web to me.
(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.)
I used it and was all-in, sure that this was going to change the interwebs overnight, kinda like I went all-in on XHTML & semantics (eg microformats).
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.
I ran into some folk who shared their torrent folder. These curated lists were something wonderful. You could even ask if something could be seeded. It elevated BitTorrent to new levels: You could make a torrent from anything, it made it available automatically and if someone showed an interest in it it was easy to switch on seeding. We had lots of fun watching old black and white movies.
"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 it's finally happening. It wasn't right time when it was introduced. We had to see bad side of centralisation to eventually go in direction of decentralisation which was what original Internet was meant to be.
Opera Unity (or was it called Unite?) really taught me to never ever use proprietary software, since it all can go poof overnight without any chance of getting it back. I really liked Opera Unity. I had my own little website and stuff.
There are always tradeoffs. DHT resolution may never be as fast centralized solutions. And as far as I know there's still no general solution to certain attacks like sybil. An intermediate solution that works with today's technology is for people to self-host "partially centralized" technologies, a la federation, but the UX is currently prohibitive. I don't want to manage 5+ instances for all the services I'm interested in and I also don't want to pay $5/mo to have someone else manage all of them, and still be stuck coordinating all those accounts. I'd love to see something like sandstorm.io as a service become popular for federated tech.
DHT perf, sybil resilience, and metadata exposure are weak points in p2p. There are ways to mitigate its necessity: SSB removes the DHT entirely and gossips data through a topology which users configure (on network or via manual setup). At this stage I think you want a hybrid so that you can reliably find data via the DHT, but then move away from the DHT when possible. Once you have reliable supernodes, its feasible that you'd check with them first over an existing connection prior to hitting the DHT.
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.
I think the human cost aspects of federation could work like subreddits in terms of the amount of work necessary to keep things running relatively smoothly. The tooling likely needs to get way better though.
We can use the same logic (I mean ignorance) as with bloatware and other hipster bug hives: "Just buy a faster everything." (or even: "everyone has fast everything now")
To clarify: there absolutely is a server in your browser. You can see its implementation in the `socketMessageListener` function. The fact that you choose to call it "shooting" instead of "serving" does not change that.
My definition would be if it’s largely sitting around doing nothing until a request comes in, and its job is to answer and service those requests, then it’s a server.
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.
> By extension of that argument you could argue that no server is a true server
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.
Your confusion is because you assume the requests have to come in via individual sockets, but several distributed designs have servers connect to a frontend and wait for requests instead of having the frontend connect. Many servers are also clients of another service.
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.
It's waiting for a request to serve content over a network.
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.
The fact that it is not listening on an incoming network port makes it less of a server IMO. Proxies still proxy things back to another server that is listening for TCP connections, not to a client that has previously initiated a connection to the proxy.
A traditional proxy server is a server and a client. A server to the downstream clients, and a client to the backend servers.
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.
Isn't this pretty much a proxy, and like how nearly production environment on the web works? I don't see how this is any different than using Nginx or Apache in-front of your "server."
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...
We've been working on a very similar idea to this for the past few months: https://pocketweb.io
There is a very early beta available on both iOS and Android. We've thought a lot about battery and data and have gotten really good results by leveraging existing radio wakeups, batching requests, and doing all sorts of optimizations to the sites themselves.
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.
This reminds me of the time Opera made some big annoucement in 2009 that they were going to "reinvent the web", and when they finally revealed what it was, it was basically host some files from your browser.
And that's where Opera failed. Marketing. It was much more than just "host some files from your browser"; if was a full ecosystem with a "app-store" and technology that made it work behind NATs etc.
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!)
But... that's huge. And it is a big step toward a necessary reinvention of the web. There is more that's needed but that's absolutely a big piece of it.
I remember using Opera coupled with a Java program which repeatedly took screenshots to create rudimentary online streaming. This was back before Twitch.tv, when web streaming was low-quality. The screenshot stream allowed me to clearly read the text chat and monitor enemy player activity in an MMORPG running at home, from school computers.
Personal plug: if you want something similar that supports Range requests (ie streaming), check out fibridge[0][1][2]. However, I haven't tried adding support for setting web mime types so you can actually run a website off of it like hostyoself. That's any interesting use case that I'll have to look in to.
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.
Doesn't the same hold for any publicly accessible platform where people can post stuff? Eg. instagram, youtube, facebook... They can deal with it in the same way: someone complains, you kill it off :-)
I would argue it is true for user-hosted content sites but it not true here (see my previous reply). This solution is not hosting the content at all.
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.
Not a professional liar either but I'm not sure about that. I imagine torrent trackers are a decent analog thats been through the courts already. They don't host the content, they just host URIs and metadata to people that host the content.
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.
> 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.
That's what I've understood, they'll have to provide bandwidth, and they'll have to use as much upload as download (though that's rarely a problem).. But still, scaling it would be interesting, but as a proof of concept it's still interesting, as they're not providing storage or processing.
I'm more curious as to the legal implications of what people might share when using the service, even if (s)he's not the one hosting, (s)he's providing bandwidth and enabling access.
Just as any other intermediate device, service, or system is doing.
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.
That's why it's interesting, in Sweden a person is = IP. Which in this case is considered the owner. There's also been a case recently where a private person has been hold personally responsible for other peoples facebook comments.
Underwhelming, this just proxies the request through an external web server that handles it.
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.
Using these technologies instead of OP centralized proposition would improve reliability, scalability, security and sustainability : currently hostyoself.com returns a 502 bad gateway.
[1]: https://github.com/mozilla/libdweb