I think the main problem is this fascination with building sub-standard cryptographic primitives into the network layer. NFC should just be a transparent network transport, assumed to be insecure. That higher level protocols can use for key exchange and other encrypted tunnel protocols.
Joe average user doesn't care about increasing their phones storage after purchase, or hot-swapping between a collection of micro sdcards that are far too easy to misplace. Provided it has a reasonable sized internal storage and I can hook it up to a PC to easily swap things around, I don't care either.
Android only for the moment. Though we haven't actively tried to promote the application, there have been burst of new users after a few minor announcements or other media attention.
You could sign up to our developer email list, I don't think we have a low traffic announcements list.
Anyone who wants to use our daemon as the basis of a port to other platforms is welcome to start one.
We've also got an asterisk channel driver, if you'd like to use any other voice protocol like SIP to talk to other Serval phones or use Serval phones as extensions in an office PBX. But I wouldn't call either of those options polished.
I think the project has a lot of potential. We've invested a lot of time in the last year building our basic set of services to a demonstrable state. Though there's always something else that could be improved.
No it really is. Serval is building an encrypted, *decentralised* communication platform, that can also route packets over a local mesh network. Initially including voice, text, and file transfer services. But that doesn't mean we are forever limited to only supporting communications over a local mesh, or that we will be limited to this set of secure services. Just that providing communications in an emergency, without supporting infrastructure, is our main focus. Everything must always work in isolation.
I've already experimented with a prototype internet directory service, combined with a packet relay service that could provide Serval to Serval internet calling right now. Implementing it was fairly easy. But we really need to use a Distributed Hash Table for scalability, and provide a separate STUN-like 2-way NAT traversal service to punch direct p2p paths through the internet. Then we won't need to provide much supporting infrastructure at all. Since these services would be run by the very people using the network, I'm not even sure what service we could justify charging for. Except perhaps for terminating calls to the PSTN, which is also a capability we've already built.
Basically I'm saying that with only a couple of months of dedicated effort (and funding....) we could be providing the exact same service as Silent Circle for a fraction of the cost. Though we only have an android client right now, we test our back end daemon on linux & OSX and could start building a desktop front end.
We're getting close to releasing an alpha version of 0.90. This represents a major leap forward under the hood from the current 0.08 version available on the android market. 0.08 is a collection of loosely related applications held together with string and sticky tape; BATMAN, asterisk, wifi-tether, dna & SipDroid. For 0.90 we've rebuilt the core of our solution from the ground up and thrown away the pieces that never really fit together that well in the first place. We're not ready to call it version 1.0. There's still a lot to do before we reach that point, but 0.90 is a *lot* closer to where we wanted to be.
So similar to the set of services that the Serval Project (my current employer) is aiming to deliver? But it costs $20 a month, and it only works when you have a viable internet connection to their servers?
When the Serval product set grows to include an internet directory service, I'm certain we'll be able to run it for less than $20 a month. Probably for less than $20 a year.
Diablo 3 will become unplayable if your internet connection to those servers is too laggy.
I tried the open beta, through my ISP it was a slideshow where I didn't know if I was alive or dead. Admittedly a few tweaks to their QOS rules probably sorted everything all out for the games release, but why should I have to risk dieing due to lag in a single player game?
And all ISP's basically have to sell through them. NBN's pricing model makes it basically impossible for small operators to compete. Personally I don't think the NBN should not be driven by profits. It's a utility with a natural monopoly. Pay the big up-front costs via taxation, with running costs passed on to customers. Why should we give private investors the right to gouge us for more profits 20 years from now?
I know other people have picked on this statement already, here's another perspective.
From your frame of reference you have a "light cone", eg light emitted from events inside that cone has already reached you. Events inside this cone can absolutely be said to have occurred in your past. Events inside this cone could have influenced you and caused you to do something. There is another light cone spreading out from you that includes events that you could influence.
For an event that happens outside of these cones, there is no way for you to know if this event happens "before" or "after" your present time. In fact, there will be a frame of reference where an observer will measure the event as being before your present time, and another frame of reference that will measure this event as being after your present time. Attempting to establish the chronological ordering of events that occur outside of your light cone is meaningless.
So if you could travel FTL, to a point corresponding to "now" outside your light cone. And another observer in a different reference frame does the same in the other direction. It is perfectly possible for both parties to arrive before the other one left, because both parties have a difference definition for "now" for events outside their light cone.
Remote access is not what Wayland is for. The implementation of X11 has historically been responsible for too many different services that should have been separated a long time ago. From mode setting to compositing, to the interface for separate window management, the implementation of X11 has been showing its age for a long time. Wayland is about compositing your local desktop. Taking over a number of roles that X has historically served, while still allowing you to use X or other network protocols for remote access.
Music playback doesn't require low latency; it doesn't matter if the music player has to process 500ms of audio before you hear the music.
FTFY, a fast CPU won't necessarily take 500ms to decode the first 500ms of audio, but since it already has all of the audio data it can take as long as it needs to. I know that's almost uselessly pedantic. The best kind of pedantic.
Raise it to a 5 minute heart beat, with any buy & sell orders at the same price matched off. More of one type than the other? Pick the winners randomly.
Plus the raspberry pi has all of the I/O ports you need to actually use it. This CPU card might form the core of another product, like a tablet, but as a minimum you'd need a docking station to connect to everything.
The Serval Project is working towards solving these kinds of issues. A group of people in a ravine can use our software to form a mesh network and communicate among themselves. Our file distribution process will attempt to replicate encrypted data to everyone running our software, so a text message / voicemail / photo / GPS fix can be shared with the rest of the team even with only intermittent connectivity. You could even send an sd card via avian carrier, if that's the only option available. Then a single person with cell phone coverage or a satellite terminal can upload everything that's relevant to anywhere in the world.
These are the kinds of use cases we've been working towards for a couple of years now, and we think we're getting close to something usable.
For source code you could commit them into git repo's in whatever folder structure you have. Create separate repo's for each project or sub folder, or just one big one.
Then just push each project with a unique branch name into a single bare repository. git can automatically find duplicates, compare similar objects looking for ways to store them using delta compression, and then compresses everything. This works across the entire repository, even if the code is stored internally in different branches.
Our focus is on providing useful services without any reliance on fixed infrastructure. Phone calls and text messaging via adhoc mesh, and even file distribution in the field.
Though you might find our next release more suitable than the version on the market. It's still in heavy development, but would also allow phone calls to be relayed to the PSTN via an asterisk PBX. We'd be happy to provide an alpha version and help you to get the most use out of it.
We're also working on a separate application that uses open street map data for situational awareness and collaborative mapping.
Enrich it in Australia, and elsewhere, where it is actually mined. Not sure if that would actually save on transportation costs, even though you are transporting less volume and mass, you are transporting something inherently more dangerous.
If we're going to send more probes / spaceships out into the universe, collecting reaction mass from the moon would be more energy efficient than lifting it from the earth. Even if we can't use that mass directly as an energy source.
I should point out that adhoc mode on android is not supported and not well tested on most handsets. Our approach is based on a much earlier tethering application that requires root to reload the wifi driver and set it's mode. Some later versions of android though have explicitly disabled adhoc mode so even that approach wont work. However our software can also work when connected to an access point, and most phones allow the built in hotspot to be turned on, so you can still setup a network in an emergency or disaster with just mobile phones.
The Serval Project is aiming to do exactly this (disclosure, I'm working for them ATM). Use the Wifi chip in android phones to create an adhoc network for situations where the phone network is down or non-existent. It's still alpha quality at this point, but we're working on phone calls, text messaging and file distribution using strong cryptography, without any central administration or infrastructure. And we're planning to use our file distribution system for a bunch of other services like collaborative mapping.
Slashdot Mirror
I think the main problem is this fascination with building sub-standard cryptographic primitives into the network layer. NFC should just be a transparent network transport, assumed to be insecure. That higher level protocols can use for key exchange and other encrypted tunnel protocols.
Joe average user doesn't care about increasing their phones storage after purchase, or hot-swapping between a collection of micro sdcards that are far too easy to misplace. Provided it has a reasonable sized internal storage and I can hook it up to a PC to easily swap things around, I don't care either.
You could sign up to our developer email list, I don't think we have a low traffic announcements list.
Anyone who wants to use our daemon as the basis of a port to other platforms is welcome to start one. We've also got an asterisk channel driver, if you'd like to use any other voice protocol like SIP to talk to other Serval phones or use Serval phones as extensions in an office PBX. But I wouldn't call either of those options polished.
I think the project has a lot of potential. We've invested a lot of time in the last year building our basic set of services to a demonstrable state. Though there's always something else that could be improved.
No it really is. Serval is building an encrypted, *decentralised* communication platform, that can also route packets over a local mesh network. Initially including voice, text, and file transfer services. But that doesn't mean we are forever limited to only supporting communications over a local mesh, or that we will be limited to this set of secure services. Just that providing communications in an emergency, without supporting infrastructure, is our main focus. Everything must always work in isolation.
I've already experimented with a prototype internet directory service, combined with a packet relay service that could provide Serval to Serval internet calling right now. Implementing it was fairly easy. But we really need to use a Distributed Hash Table for scalability, and provide a separate STUN-like 2-way NAT traversal service to punch direct p2p paths through the internet. Then we won't need to provide much supporting infrastructure at all. Since these services would be run by the very people using the network, I'm not even sure what service we could justify charging for. Except perhaps for terminating calls to the PSTN, which is also a capability we've already built.
Basically I'm saying that with only a couple of months of dedicated effort (and funding....) we could be providing the exact same service as Silent Circle for a fraction of the cost. Though we only have an android client right now, we test our back end daemon on linux & OSX and could start building a desktop front end.
We're getting close to releasing an alpha version of 0.90. This represents a major leap forward under the hood from the current 0.08 version available on the android market. 0.08 is a collection of loosely related applications held together with string and sticky tape; BATMAN, asterisk, wifi-tether, dna & SipDroid. For 0.90 we've rebuilt the core of our solution from the ground up and thrown away the pieces that never really fit together that well in the first place. We're not ready to call it version 1.0. There's still a lot to do before we reach that point, but 0.90 is a *lot* closer to where we wanted to be.
So similar to the set of services that the Serval Project (my current employer) is aiming to deliver? But it costs $20 a month, and it only works when you have a viable internet connection to their servers?
When the Serval product set grows to include an internet directory service, I'm certain we'll be able to run it for less than $20 a month. Probably for less than $20 a year.
Yes, yes it does.
Diablo 3 will become unplayable if your internet connection to those servers is too laggy.
I tried the open beta, through my ISP it was a slideshow where I didn't know if I was alive or dead. Admittedly a few tweaks to their QOS rules probably sorted everything all out for the games release, but why should I have to risk dieing due to lag in a single player game?
And all ISP's basically have to sell through them. NBN's pricing model makes it basically impossible for small operators to compete. Personally I don't think the NBN should not be driven by profits. It's a utility with a natural monopoly. Pay the big up-front costs via taxation, with running costs passed on to customers. Why should we give private investors the right to gouge us for more profits 20 years from now?
Speak for yourself, I want to use phone hardware to run applications almost continuously, mainly for mesh networking, with the screen off.
an absolute frame of reference
I know other people have picked on this statement already, here's another perspective.
From your frame of reference you have a "light cone", eg light emitted from events inside that cone has already reached you. Events inside this cone can absolutely be said to have occurred in your past. Events inside this cone could have influenced you and caused you to do something. There is another light cone spreading out from you that includes events that you could influence.
For an event that happens outside of these cones, there is no way for you to know if this event happens "before" or "after" your present time. In fact, there will be a frame of reference where an observer will measure the event as being before your present time, and another frame of reference that will measure this event as being after your present time. Attempting to establish the chronological ordering of events that occur outside of your light cone is meaningless.
So if you could travel FTL, to a point corresponding to "now" outside your light cone. And another observer in a different reference frame does the same in the other direction. It is perfectly possible for both parties to arrive before the other one left, because both parties have a difference definition for "now" for events outside their light cone.
Remote access is not what Wayland is for. The implementation of X11 has historically been responsible for too many different services that should have been separated a long time ago. From mode setting to compositing, to the interface for separate window management, the implementation of X11 has been showing its age for a long time. Wayland is about compositing your local desktop. Taking over a number of roles that X has historically served, while still allowing you to use X or other network protocols for remote access.
Music playback doesn't require low latency; it doesn't matter if the music player has to process 500ms of audio before you hear the music.
FTFY, a fast CPU won't necessarily take 500ms to decode the first 500ms of audio, but since it already has all of the audio data it can take as long as it needs to. I know that's almost uselessly pedantic. The best kind of pedantic.
Raise it to a 5 minute heart beat, with any buy & sell orders at the same price matched off. More of one type than the other? Pick the winners randomly.
Really?
Plus the raspberry pi has all of the I/O ports you need to actually use it. This CPU card might form the core of another product, like a tablet, but as a minimum you'd need a docking station to connect to everything.
// Add 1 to i
i+=2;
The Serval Project is working towards solving these kinds of issues. A group of people in a ravine can use our software to form a mesh network and communicate among themselves. Our file distribution process will attempt to replicate encrypted data to everyone running our software, so a text message / voicemail / photo / GPS fix can be shared with the rest of the team even with only intermittent connectivity. You could even send an sd card via avian carrier, if that's the only option available. Then a single person with cell phone coverage or a satellite terminal can upload everything that's relevant to anywhere in the world.
These are the kinds of use cases we've been working towards for a couple of years now, and we think we're getting close to something usable.
For source code you could commit them into git repo's in whatever folder structure you have. Create separate repo's for each project or sub folder, or just one big one.
Then just push each project with a unique branch name into a single bare repository. git can automatically find duplicates, compare similar objects looking for ways to store them using delta compression, and then compresses everything. This works across the entire repository, even if the code is stored internally in different branches.
The Serval Project on the Android Market.
Our focus is on providing useful services without any reliance on fixed infrastructure. Phone calls and text messaging via adhoc mesh, and even file distribution in the field.
Though you might find our next release more suitable than the version on the market. It's still in heavy development, but would also allow phone calls to be relayed to the PSTN via an asterisk PBX. We'd be happy to provide an alpha version and help you to get the most use out of it.
We're also working on a separate application that uses open street map data for situational awareness and collaborative mapping.
Enrich it in Australia, and elsewhere, where it is actually mined. Not sure if that would actually save on transportation costs, even though you are transporting less volume and mass, you are transporting something inherently more dangerous.
Reaction mass.
If we're going to send more probes / spaceships out into the universe, collecting reaction mass from the moon would be more energy efficient than lifting it from the earth. Even if we can't use that mass directly as an energy source.
I should point out that adhoc mode on android is not supported and not well tested on most handsets. Our approach is based on a much earlier tethering application that requires root to reload the wifi driver and set it's mode. Some later versions of android though have explicitly disabled adhoc mode so even that approach wont work. However our software can also work when connected to an access point, and most phones allow the built in hotspot to be turned on, so you can still setup a network in an emergency or disaster with just mobile phones.
The Serval Project is aiming to do exactly this (disclosure, I'm working for them ATM). Use the Wifi chip in android phones to create an adhoc network for situations where the phone network is down or non-existent. It's still alpha quality at this point, but we're working on phone calls, text messaging and file distribution using strong cryptography, without any central administration or infrastructure. And we're planning to use our file distribution system for a bunch of other services like collaborative mapping.
Speaking of custody chains for data, shouldn't they just hash the data when they duplicate your drive, cryptographically sign it and print a receipt?
Here's another link explaining some of the issues with getting thunderbolt to work.