[creat0]

Do you think the possibility of "always on" computers at home (e.g., running low power ARM CPU's) is a real one?

Would this change the way we think about "reliability"? (Of course the canonical example of the need to be "always on" is email. We've come to expect that the server handling our mail is always up.)

[EvanAnderson]

I think that low-power computers are the future of "always on". I'm migrating the "always on" home computers I use, and those of my family members, in that direction.

I don't think email is a good "host at home" candidate, personally. Anti-spam services benefit too much from an economy of scale that comes from shared hosting. Having said that, though, I've hosted my email (SMTP and IMAP) on a consumer-grade Internet since June 2004. I've had outages because of service-provider issues (Time Warner) once in awhile, but the outages of significant duration (24 - 36 hours) have been either I was using unreliable old hardware. In those outages my secondary MX picked up my mail just fine and I worked from cached email on my personal computers.

Assuming I was using more robust hardware or, for that matter, more simple hardware (a plug-computer that I could swap with a spare, moving an SD card containing all my email and configuration between) I wouldn't have ever had an outage longer than 8 hours since 2004. If the server was in a larger city (rather than the rural setting where it's hosted) I don't think I would have suffered thru than 8 hour power outage, either.

The Tent protocol sounds like something that would work best hosted by your ISP, a third-party hosting service, or a rented platform in a third-party data center ("the cloud"). (It actually sounds like a naive re-implementation of some of the functionality of SMTP.)

The things I'm most interested in hosting at home are things like home automation and Internet-connected appliances / devices. These products typically aren't going to be receiving requests from a large number of Internet hosts, don't necessarily need 24 x 7 uptime, and, most importantly, won't work if the home's Internet connection or power has failed (and, thus, don't gain any reliability benefit by being "cloud"-based).

[donkeylipstick]

I have a Mac Mini on 24/7 that's a web/mail/file server. This is for my small business, so there is activity but nothing heavy. Absolutely more than capable of adding a dozen people for social networking.

This consumes 12W while idle, which is probably 99.9% of the day, these are just background daemons carrying out requests all day for loading the website and sending/receiving email.

It's cheaper than a hosting service and I have 100% physical control over my server. If it goes down for a power outage or whatever, the same exact thing happens on Linode every few months. Email will just start to backlog until your server comes back online.

You are at the mercy of your ISP though, the biggest hurdle is port blocking if they're bastards about it. Most of them are, but there are ways around it.

http://images.apple.com/environment/reports/docs/macmini_per...

[creat0]

This is the answer I was hoping for. I know of at least one solution for your ISP concerns. I think it will work very nicely.

ISP's can obviously block anything they want to block. But with bigger bandwidth and things like VOIP services on the rise I would think that means letting some regular customer UDP traffic pass in/out. In your opinion, would you think that most ISP's would not allow customers to keep some long-term UDP "connections" open on any port? I have not had any trouble with this in the places I've tried, but it's hard to know what most ISP's do. Honestly I just can't see any reason they would block a low number of low traffic UDP peer-to-peer connections per customer (the customer's social network), when you consider they are allowing things like Bittorrent which are huge network hogs by comparison and are being blatently used for the sole purpose of downloading bootlegged entertainment media from random strangers.

The interesting thing is that if we can achieve this sort of peer-to-peer social networking, concerns about email servers being online, at least with respect to mail that you send to people on your social network, may turn out to be less of an issue. Why do I say this? Because the reason you want your email servers to always be up is so you can receive mail as timely as possible. Ideally you would like to have near "real-time" mail. Otherwise, if time is not an issue, then storing messages for pickup later on, e.g. in the cloud, should be fine. But if you and I are both on a private peer-to-peer social network, all that's required to send "real-time" email (or whatever format of bits you choose) is that we are both logged in. We might leave low power machines on in order to stay logged in over long periods. I would guess this might be a much more popular form of "email" between friends and family.1 Remember the UNIX programs talk and finger?

1. Obviously there is no spam. The only people who can send and recieve mail to members of the peer-to-peer private social network are those who are logged in. Spammers can't log in. Nor can they be bothered to try to crack their way into myriad disparate small p2p social networks.

[e12e]

I've been having a server "always on" at home since the early 2000s (in the 90s I would've run a BBS if not for the fact that Norway have never had free local telephone service -- and we only had the one phone line).

If I used that availability to host a web page and/or receive email via smtp -- such services would certainly be handled handily by a solid-state disk and an arm cpu -- maybe a rasperry pi? Or just a cheap, rooted, android phone plugged into the charger. Then I'd have redundant networking (4g and wireless to my adsl2-line -- shouldn't be too hard to whip up something that would work, perhaps using the android scripting framework [1]).

Currently I use it to have access to some of my (personal) files, schedule/check on downloads and updates, and haven't quite been able to whip my providers broadband router into shape (the box tends to go flaky every 7-10 days of uptime, probably due to buggy wireless) -- so it's nothing I consider "service grade" right now.

But distributed twitter done right, with several layers of caching (see the Fielding thesis on REST [2]) -- shouldn't really need much in terms of traffic to host my tweets/updates.

I still think an smtp/mailinglist/uunet/usenet design would work/scale better though.

But then how would we track users, spam them with ads and monetize something that takes so little infrastructure to run in a decentralized manner that there is no real need to monetize it? /rant

[1] http://code.google.com/p/android-scripting/ [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm