Innovative Uses for App.Net

There have been some discussions about innovating on App.Net. I think the biggest limitation is getting past the use of alpha as a Twitter-style service. I offer some neat ways to use app.net.

These ideas are free to the public domain. I hearby give up all rights to the ideas or the benefits that come from implementing them. (Just in case they’re good ideas, I want someone to build them)

Idea #1: Growl for Your Life

Lots of things can do syslog-style messaging to you: apps on your computer, sites that you use, even ecommerce shops and banks and things. What if you could give your app.net userid to them all, and then they would send data to you:

  • Balance notices from the bank
  • eBay bidding / selling notices
  • eFax fax received notifications
  • Syslog-style information from computer systems
  • Weather, horoscope, stocks, etc.
  • IPv6 connected home appliances (like your refrigerator telling you to buy milk)

For those of you who don’t know what Growl is, take a look. App.Net becomes a set of streams for you and your stuff. Using App.Net this way becomes a lot easier if you then have:

Idea #2: Outlook for App.Net

No, not really, but yes, really. We need a client that can handle lots and lots of streams based on various criteria and put them in ‘Folders’ or “pipes” or something. The idea being that all those Growl-like streams will produce tons of posts that you don’t want polluting your main stream. You need rules to file them off and hang onto them for a little while. No, this isn’t email, but we don’t want them flowing by so fast we don’t read them.

One of the features that Outlook can do would also be good on App.Net:

Idea #3: Encrypted Posts

Using a combination of direct messages and public posts, we can do encrypted posts. First, everyone has to have public keys in a public place, and private keys in their client. Public keys distributed, trusted, signed, revoked, etc. is an incredibly hard problem, and not one we’re going to solve any time soon. So we’ll do it ad hoc like we always do. Private keys in clients is trickier, but feasible.

If I want to create an encrypted post, I choose a 256-bit, random AES key for it. I encrypt my post using that key. (I probably encode the encrypted data using Base16k—Thanks @ravisorg). The client posts it and looks to see what unique ID is assigned (e.g., 1444223). Now my client asks me to select recipients. I pick 3 or 4 or however many.

For each recipient, my client encrypts the AES key for the post using their public key. Then it sends them a direct message that basically contains just the post number (e.g., 1444223) and the AES key for it, encrypted with the recipient’s public key. To be more efficient with subsequent messages, I could reuse the same AES key for several messages in a row. I would just send DMs to the recipients saying something like 1444308 = 1444223, which lets their clients know that the key they used to decrypt 1444223 can also be used to decrypt 1444308.

For this idea, I have clearly waved my hands over a bunch of classically difficult problems in encrypted messaging:

  • Public key management (trust, revocation, finding keys, distributing keys, etc)
  • Private key management (safely storing them, using them in the client, etc)
  • Digital signatures and/or integrity indicators

Conclusion

So there’s some nifty uses for App.Net that you probably won’t see allowed on it’s bird-brained predecessor.