Mersenne number primitive root conjecture

2 seems never to be a primitive root of a Mersenne number (and consequently Mersenne primes). Even more strongly, it eliminated by (p-1)/2

forprime(i=3,10000,p=2^i-1;g=Mod(2,p)^((p-1)/2);if(g!=Mod(1,p),print(i)))

Peer to peer distributed

Facebook, by bits and pieces, slowly becomes evil, finding creative ways of pushing the boundaries to sell users' privacy to generate revenue. It's partly caused by greed (of course, the venture capitalists want to make money!), but ultimately, someone has to pay the internet bill.

If there could only be a way such that we all collectively pay the internet bill, for example, as a distributed peer-to-peer application that has low (or zero) bandwidth or other requirements for the central server. Are distributed hash tables the answer?

I can imagine some sort of "status" and pride people could get in being big contributors to the hosting, which might provide incentive for people not to free ride.

Then, the incentive of greed is diminished, and the platform may be more open. The browser/viewer application may be open source, undesirable features may be removed, privacy may be audited, and the need to trust the central server and its maintainers is diminished.

Facebook itself I feel will end poorly, unless they radically change to a new model like described above. Ultimately they will probably fail to generate enough revenue, but they will have collected a giant database of every users every action (every click!) on the site. They know every photo you every looked at and when. And, if you untag a photo, did they really destroy all records of it being tagged?

Perhaps they will have one or more security breaches, possibly subpoenas, exposing this database. Or if not, they might sell this database to the highest bidder as their exit strategy.

Aggressively encrypt

Google Gmail (and others) who provide hosted e-mail may protect their users' privacy by structuring their back-end to keep things encrypted as much as possible. In the event of a subpoena or accidental security breach (but this won't stop security breaches by determined insiders) the plain text messages are simply not available.

The hosted e-mail provider maintains the user's public key (public enough for its own use; it need not be broadcast any further, though there is no danger in it), an encrypted version of the private key, messages encrypted with the public key, and an index also encrypted with the public key.

The user logs in and provides the password which is the key to the encryption (the key to an encrypted private key). The architecture (engineering challenge!) is that the plaintext key hangs around as little as possible on the servers, of course, never hitting disk, and possibly re-querying the user's brower (via cookies?) whenever the key is needed. The server in fact only gives encrypted messages to the browser, which are decrypted *by the browser* (javascript!?) to read the message.

Whenever a new message comes in (this part is unfortunately unencrypted), the server performs any actions required by the filters, then immediately encrypts with the user's public key and forgets the plaintext. At this point, the server has lost all ability to see the message until the user logs in again.

For messages between Gmail accounts (or a cabal of e-mail providers who share public keys of users), one can even avoid the initially unencrypted incoming message: let it be encrypted from end to end by the browser of the sender to the browser of the recipient.

When the user logs in to provide a password to the private key, the hosting company uses the power of ten thousand servers to rapidly decrypt and incorporate all the new mail into the mail index. (The mail index was similarly public-key encrypted like the messages.) It then again forgets the private key.

This may or may not be enough rope to allow for AdWords along side messages, but certainly a way of implementing it can be worked out while still maintaining as much encryption as possible.

Boiled garlic

I am amazed by the flavoring power of boiling something with lots of garlic and salt. I have tried vegetables (broccoli, spinach) and will next try pasta.

Registered Turing machine

The Turing machine is a wonderfully simple model of computation. But practically it is very awkward to program. Its biggest problem is the lack of random access and registers for temporary storage of results.

A register machine with RAM, that is, today's microprocessors, are convenient to program, but they have arbitrarily chosen size limits: the width of registers and the amount of RAM.

One would like to scale it up to the truly infinite (because of the infinite tape) model of computation that a Turing machine has. Here are some ideas.

Replace registers with stacks. Each stack element is a bit and the entire stack itself represents a value, possibly an address. Addresses may be arbitrarily large, because of the infinite memory available. Stacks have an advantage of tapes because its clear when you've reached the end of a stack, signifying, say the least-significat bit of the value on the stack. In order to manipulate the top and bottom bits easily (addition goes from LSB to MSB, while division goes the other way), it could be a double-ended stack with traditional stack operations available at both ends.

This is kind of a register machine where the fundamental data type is an infinite-width bit vector.

Random access into an infinite amount of memory seems a little bit absurd. It seems more realistic to have access time to be logarithmic with the length of the address. We may have a "jump left" (or right) instruction, telling the machine to move the tape head a distance to the left equal to the value stored in a particular stack register. Perhaps the logarithmic access time is already encoded in the fact that constructing the address itself already took logarithmic time.

Most modern languages have stack frames, and encoding those are awkward on a single tape. In order to hold more than one value on a stack, there are additional characters for the alphabet of the stack: "(", ")", along with "0" and "1". Perhaps the alphabet of the tape should also include them as well, so as to simplify the problem of encoding arbitrarily large values. It is up to the program to maintain consistency of what the characters mean, presumably trying to keep balanced parentheses.

We might have a few tapes (three or four) to allow algorithms like mergesort to work efficiently.

This ought to be enough rope for to develop compilers for high-level languages into this model of computation.

Offline voicemail

Better than visual voicemail would be offline voicemail. As soon as a voicemail is recorded, it is automatically downloaded to the phone. The recipient can then check the voicemail at his leisure, even when out of reception. The is not so hard at all, as voice compresses (even for storage) quite well, and there is no real-time requirement.

I would also like to be able to access voicemail via other interfaces. Sometimes, I know I am expecting a voicemail, but am stuck in a room with no reception. Perhaps Google can strike a deal with cellular providers to be able to browse and listen to saved voice-mail messages through the Gmail interface.

Encrypted cell phones

Everyone has a cell phone these days, essentially a small portable computer with a display. It is a shame that we do not regularly have end-to-end encrypted communications. There is no excuse not to. At the very least, one can start with encrypted text messages. Public keys may be exchanged via bluetooth (or infrared) if meeting in person, and the display can be used to read aloud key signatures to each other; assuming one trusts each other's voice, it can effectively thwart MITM attacks.

I feel one of the main reasons for this failure is that phone companies selfishly keep everything closed.

Array of pinhole cameras

An array of pinhole cameras, each backed with CCDs, for increased light collection and possibly stereo vision.