3 ms·

I feel like people keep trying to build distributed applications from the ground up, rather than building distributed infrastructure that applications can be bu

I feel like people keep trying to build distributed applications from the ground up, rather than building distributed infrastructure that applications can be built on top of and share. Well, the systems are being developed (cjdns/namecoin etc), but I haven't found any yet that I look at and think, wow yeah, that's usable and could work at Internet scale, I can see that installed and in use on my mums computer. If I'm building an application to allow two people to chat with each other in a p2p fashion, I shouldn't have to worry about how the two chatters will be able to find each other and set up a secure connection. I should just be able to call some OS level API to specify, "try to establish a connection with Person x to use with chat service Y" Basically, we need a way for hosts/people to find each other on the Internet and to exchange keys securely. If/once we have that it will be natural and easy to build any sort of p2p application.

amirmc 13y ago
I'm working on this along with others. Essentially, it's the infrastructure needed to build secure, distributed applications and deals with the problems of identity, connectivity and sync. It needs to be open-source with a permissive licence, otherwise it becomes just another silo. My view is that once the infrastructure is working, we need to start with the core applications of mail, contacts and calendars. Ultimately we can create a platform with something like a distributed app store that makes it easy to use the infrastructure and get it out to end-users. I'm putting together a website that describes the pieces but if you want to know more before then, please send me an email (see profile).
dtby 13y ago
I'm dead on arrival on HN, but I have built this (complete with the concept of "personas") as part of my project to revive USENET.
mike-cardwell 13y ago
dtby: Your comment is hidden as you're account is "dead". I realise you already know this. I would be interested in seeing what you've built... Contact details are in my profile, or you can reply here again.
gwu78 13y ago
It sounds like what you want is "CaaS". Connectivity as a Service. Specifically, connectivity that allows unrestricted two-way communication between end users. "Unrestricted" as used here refers to restrictions arising from firewalls and NAT. This sounds simple enough. So why isn't it a standard offering? Only the connection. Not the connection as part of an application that uses the connection. Only the connection on its own. IOW, what you see when you type ipconfig or ifconfig. A connection that can then be used by any application. A user might use have some applications use this connection (i.e. interface), but not others. Her ISP-provided connection to the Internet and her CaaS connection to a small user-created VLAN overlay network can be separated on the logical interface level. One way to envision this is the CaaS provider gives the user what she needs to make her own small overlay networks. App developers might provide LAN-based applications to run on top. Everyone reading this online has connectivity to "the Internet". But the vast majority of end users do not have connectivity that allows unrestricted two-way communication with each other. Instead they must communicate through a third party such as an email provider (e.g. Gmail) or a website (e.g. Facebook). Firewalls allow ingress traffic coming from such third parties. Those third parties generally monitor and often analyze all traffic that passes through them, usually for commercial benefit. Perhaps they store it as well. Regardless of the security or privacy implications of this model, communication via a third party is often inefficient. Why should two users in the same country who wish to send data to each other be required to send their data to a datacenter in a different country in order to communicate? To take but one very basic example, consider email. What if end users ran their own SMTP servers and these servers communicated directly? There would be no need for "email providers". This is not so far-fetched as it might sound. In the early days of the Internet, there were no commercial email providers acting as "gatekeepers" of email, as there are today. And if you go back far enough, there were also no domain names nor centralized pseudo-authorities (ICANN and its "authorized" registrars), who constitute an additional gatekeeper. As it stands today, you generally need both a preferred IP address and a registered domain name to reliably send email, not to mention the permission of your ISP. There was much less centralization and control in the early Internet and it was far more fun (and I would argue far more useful). Email users could communicate based on mailbox name and IP address, and without involving third party SMTP servers. Imagine the simplicity. Connectivity as a Service could make decentralized, user-controlled email again possible for subscribers of different ISP's. It could also make many other otherwise "impossible" Internet uses possible. I posit CaaS could increase the value of the Internet as a whole. Internet centralization and its incumbents may be ripe for disruption. We might innovate toward more decentralized uses of the Internet than centralized ones. Then again, CaaS may not be what you want. I may have misinterpreted what you were describing.

amirmc 13y ago

I'm working on this along with others. Essentially, it's the infrastructure needed to build secure, distributed applications and deals with the problems of identity, connectivity and sync. It needs to be open-source with a permissive licence, otherwise it becomes just another silo. My view is that once the infrastructure is working, we need to start with the core applications of mail, contacts and calendars. Ultimately we can create a platform with something like a distributed app store that makes it easy to use the infrastructure and get it out to end-users. I'm putting together a website that describes the pieces but if you want to know more before then, please send me an email (see profile).

dtby 13y ago

I'm dead on arrival on HN, but I have built this (complete with the concept of "personas") as part of my project to revive USENET.

mike-cardwell 13y ago

dtby: Your comment is hidden as you're account is "dead". I realise you already know this. I would be interested in seeing what you've built... Contact details are in my profile, or you can reply here again.

gwu78 13y ago

It sounds like what you want is "CaaS". Connectivity as a Service. Specifically, connectivity that allows unrestricted two-way communication between end users. "Unrestricted" as used here refers to restrictions arising from firewalls and NAT. This sounds simple enough. So why isn't it a standard offering? Only the connection. Not the connection as part of an application that uses the connection. Only the connection on its own. IOW, what you see when you type ipconfig or ifconfig. A connection that can then be used by any application. A user might use have some applications use this connection (i.e. interface), but not others. Her ISP-provided connection to the Internet and her CaaS connection to a small user-created VLAN overlay network can be separated on the logical interface level. One way to envision this is the CaaS provider gives the user what she needs to make her own small overlay networks. App developers might provide LAN-based applications to run on top. Everyone reading this online has connectivity to "the Internet". But the vast majority of end users do not have connectivity that allows unrestricted two-way communication with each other. Instead they must communicate through a third party such as an email provider (e.g. Gmail) or a website (e.g. Facebook). Firewalls allow ingress traffic coming from such third parties. Those third parties generally monitor and often analyze all traffic that passes through them, usually for commercial benefit. Perhaps they store it as well. Regardless of the security or privacy implications of this model, communication via a third party is often inefficient. Why should two users in the same country who wish to send data to each other be required to send their data to a datacenter in a different country in order to communicate? To take but one very basic example, consider email. What if end users ran their own SMTP servers and these servers communicated directly? There would be no need for "email providers". This is not so far-fetched as it might sound. In the early days of the Internet, there were no commercial email providers acting as "gatekeepers" of email, as there are today. And if you go back far enough, there were also no domain names nor centralized pseudo-authorities (ICANN and its "authorized" registrars), who constitute an additional gatekeeper. As it stands today, you generally need both a preferred IP address and a registered domain name to reliably send email, not to mention the permission of your ISP. There was much less centralization and control in the early Internet and it was far more fun (and I would argue far more useful). Email users could communicate based on mailbox name and IP address, and without involving third party SMTP servers. Imagine the simplicity. Connectivity as a Service could make decentralized, user-controlled email again possible for subscribers of different ISP's. It could also make many other otherwise "impossible" Internet uses possible. I posit CaaS could increase the value of the Internet as a whole. Internet centralization and its incumbents may be ripe for disruption. We might innovate toward more decentralized uses of the Internet than centralized ones. Then again, CaaS may not be what you want. I may have misinterpreted what you were describing.