imaginator

It looks like the road was constructed to serve the four hydro facilities that generate power for Montreal. https://openinframap.org/#7.12/53.8/-74.103/A,B,E,I,L,O,P,T show's the hydro facilities and power lines weaving their way down to Montreal.

Jameson Lopp maintains a comprehensive list at https://github.com/jlopp/physical-bitcoin-attacks

Side joke: with inflation the XKCD $5 wrench attack (https://xkcd.com/538/) is no longer possible.

This looks like Coinmarketcap.com but for physical coins. Nice.

I'm not sure I understand the name ColCur? Maybe RealCoinMarketCap? ;)

These rope bridges would seem to make easy pickings for raptors looking for an easy snack.

This is a good example of make it easy for others to say yes.

The closest I've found is this one, but as you say, it's rather sparsely populated terrestrially: https://openinframap.org/#5.33/19.676/-108.238/P,T

This is with an application specific username/password pair that GoogleDNS gives you. And will only update that specific record.

Zimbabwe has entered the room. Also had a central bank before the last round of hyperinflation/reset. One could argue that the lack of a central bank is a feature. What other differences would would you imagine distinguish bitcoin from central bank currencies?

You might want to look into the Lightning Network - this enables instant payments on top of Bitcoin.

I went down the rabbit hole of trying to work out what this is. In involves new coins and ICOs. I'll stick with Matrix and Signal.

"Session is enabled by services provided through the Loki blockchain network. The Loki cryptocurrency is a fundamental part of these services, providing an anonymous way to transfer value between people. A lightweight wallet integrated into the Session app, using keys derived from the users existing keypair, could allow users to quickly and privately transfer value inside Session."

This sounds like AOL in 1997 saying "We are the Internet", when the real internet was accessed using Netscape.

I'm running a very similar setup. One of the HUGE benefits of these boxes is the iLO for fixing grub, / hardware changes / etc. Saves schlepping a motitor and just makes life so much easier.

What a horrible article. This article starts with the assumption American=Good/Foreign=Bad. Complete with a scaremongering title.

"repair shops thousands of miles away, in developing countries, where the mechanics who take the planes apart (completely) and put them back together (or almost) may not even be able to read or speak English."

Because developing countries are worse at this? Jets are designed to be maintained. It's systematic work. "Take this cowling off. Unscrew that, check this. Replace that." It's not like they are making hard drives. Oh wait. Developing countries already do that.

"But the F.A.A. no longer has the money or the manpower to do this." Wait... That sounds like the gist of the article. "FAA underfunded and unable to check check maintenance facilities"

Vanity Fair carries on with some more scaremongering:

"There are 731 foreign repair shops certified by the F.A.A. around the globe. How qualified are the mechanics in these hundreds of places? It’s very hard to check."

I usually like reading Vanity Fair articles. But this one got my "It's not American" xenophobia hackles up.

shameless-plug: We've been building the federated/anti-yet-another-silo version of this/Slack. Instanced interconnect kinda like usenet did and email does for 30-odd years now.

Our emphasis on being a tool for developers to add federated communication to their app (vs being another silo like Slack). The UX isn't nearly as polished, but it does federate with other servers using the XMPP network (e.g a conversation earlier today http://imgur.com/UL34KSF).

A developer started working on a slack-like UX and we threw up at http://buddycloud.org (https://github.com/buddycloud/buddycloud-angular-app if anyone wants to help).

+1 on Freifunk. Setup is super easy:

1) order an Ubiquiti Nanostation LOCO M2 (amazing reach and super sensitive antenna),

2) sign-up with them for a VPN key. This will keep your visitors traffic tunneled through their VPN. IF there is any problem with content infringement, it ends up on their network.

3) Flash the box with their OpenWRT port and install the VPN key.

I setup my box last week and and it's been running well (http://monitor.berlin.freifunk.net/host.php?h=imaginator). Nice to see users dropping on and off. The firmware also includes support for the Freifunk mesh network. I'm looking forward to adding more nodes to the neighbourhood and growing the wifi coverage.

Action shots: http://imgur.com/a/q7nOk (Decided that martini bottle is a better solution than the tripod)

Get started at http://config.berlin.freifunk.net/wizard/routers (disclaimer: not clear if you should/must/can be in Berlin for this to work)

tl;dr: Timelord needs financial support.

My girlfriend described protocols to me as "it's like everyone agrees to speak the same language and then you can communicate". Which is a great way to describe it.

When you have to agree to API terms / "rules of the road" in Twitter's legalease / or revocable oauth tokens, things stop being a free language.

You have a good point - the different blogging platforms do a good job. And create virtuous ecosystems around their code in the form of theme creators, hosting providers and consultants.

I think Kenton is onto a winner with Sandstorm - it stands half a chance to actually unify different blogging platforms. So while you may use a different blogging tool and comment - you have a unified email-like identity that follows you between tools, nodes and networks.

I don't think that creating systems != capitalism. Indeed companies that helped grow ecosystems (like Netscape) have been hugely successful.

I'm guessing this comes down to deciding to create money today to create a legacy later or to creating projects today that go onto become your legacy later. We each strive for what resonates with us and (hopefully) accept others that make different choices in life.

Facebook's statement: "Trust us. We'll show you ads."

App.net's statement: "Trust us. We'll charge you so you don't have to see ads."

Ello's statement: "Trust us, we won't show you ads."

The statement we deserve is akin to email's promise: you don't have to trust us; competing providers keep the ecosystem honest. (And the service is federated so you can connect with friends on other services)

Ello strikes me as another silo'd service. What happened to the dream of building "big" services that outlast a single company or team? The 30 year lifespan of SMTP+email, the 20 year life of HTTP, the 10 year life of XMPP.

Today we have users voting with their feet: eg I use Twitter/I stopped using Twitter after they pissed off the developer community.

Wouldn't it be great if we built services where the decision isn't use/don't use, more, my identity follows me to the best service provider (heh, like email!)?

The real statement should be: "you don't have to trust us, this is a protocol: - developers can write services against it, users can choose the developers service they like the best. And when that service goes pop, or the developer moves onto a new project, you are not stranded - just switch providers.

(disclaimer: this stuff makes me angry and we're trying to solve it at Buddycloud Towers)

Agree that it's shortsightedness.

But I think the problem goes much deeper: We keep building one-offs. Twitter - a one-off messaging service. Instagram - a one-off photo sharing app.

This is one of the reasons I started Buddycloud. We'd already built a nice location and social app but eschewed the VC cash to, dare I use the word, pivot, and build a different way of building apps.

Instead of building another one-off social-location-system like Foursquare, we decided it better to build a federated platform that others can then start building on. The federation and run-it-yourself mentality means that our users don't end up in the Twitpic scenario and that there are always other suppliers that will host your pictures in a compatible way. In a way that fosters competition between providers without needing to resort to switching friction cost to keep users.

In the Twitpic case, the buddycloud media server is designed to be a plug-in federated media hosting provider for each domain. Don't like how one provider is dealing with you data? Just switch.

It's not been easy to get this far, but we're starting to see traction from ex-app.net devs who are looking for something a bit more open that they can also run themselves (as a Docker container). And I still believe that the real solutions will be based on federated open systems that form a foundation so that developers can innovate further up the stack.

One of the big problems with XMPP security was testing the server's connection. It's worth pointing out that much of this move has been supported by @xnyhps project: xmpp.net. This lets you stick in an XMPP enabled site and see the results. For example: Google - https://xmpp.net/result.php?domain=gmail.com&type=server (nothing) and prosody.im: https://xmpp.net/result.php?domain=prosody.im&type=server

Be aware that push is very early. But there are two working implementations already - oTalk and Buddycloud (https://github.com/buddycloud/buddycloud-pusher). What's interesting is that we both came up with very similar solutions. So specing something official and then adapting our code to match the spec should be trivial (in the grand scheme of things).

OTR works great when both parties/clients are online.

I can't see how OTR would work when one client is offline since they need to both be online to do the key exchange dance. Happy to be corrected.

Ge0rg wrote that post shortly before the last XMPP summit. Then we put together the plans for push notifications (https://github.com/legastero/customxeps/blob/gh-pages/extens...) working in conjunction with Message archive management (http://xmpp.org/extensions/xep-0313.html) to catch up on messages that might have been missed (in your example: on your desktop client).

Background: XEPs are the protocol building blocks of XMPP.

The XSF (XMPP Standards Foundation) are working hard to make XMPP more mobile friendly. (disclaimer: I'm an XMPP board member).

There are three problems to solve:

1. knowing when to retrieve messages (push notifications)

2. retrieving messages (message archive management)

3. synchronising messages between devices (what this solves)

More background: XMPP is designed around keeping a connection open to the client and pushing through updates and new messages. These assumptions worked well in a desktop environment on a solid TCP connection. But for power, intermittent network, and mobile OS design reason, holding open a socket isn't ideal.

Push notification work because the OS provider (Apple, Google, Mozilla etc.) keep one socket open and then push through important notifications. This keeps the phone's radio from powering up for silly things like "contact came online/went offline" type messages.

A push notification might be "xyz posted ... ". Your phone needs to now come online and synchronise messages that might have been posted on your tablet or desktop client. Hence XEP-0280. It helps resync messages from other clients.

The XSF is also writing up a push notification XEP that makes it easy for mobile apps to use XMPP as a signalling channel and throw out push notification where necessary.

Poll results: http://poy.time.com/2013/11/25/vote-now-who-should-be-times-...

StartSSL offer a great service.

If you'd rather use the Java Keytool to manage your certs, I wrote up this guide on making it work with StartSSL. https://buddycloud.org/wiki/buddycloud_SSL_setup

Should just be a copy paste, wait, paste, export job.

I can understand licensing issues. But since Airplay only runs on the local network segment, this shouldn't be an issue.

Archive.org has some Byte Magazine back issues (eg: http://archive.org/stream/BYTE-1993-05#page/n11/mode/2up)