What does this have to do with Mosuki? Well, although it’s astronomically unlikely that FriendFeed got the idea from Mosuki, we can’t help but point out with a grin that Mosuki has separated your public list of friends from the list of people who you actually share events with, and hear about events from, since our very first release, in 2004. Acknowledging the necessity of artificial attention is a critical insight, and it takes any social site one step closer to mimicking real social interaction and being a truly useful tool.

How does Mosuki know what your favorite bands are? Magic! Just go here. If you use iTunes, Mosuki will read your iTunes library and figure out your favorite bands. If you use last.fm or iLike, type in your last.fm or iLike username, and Mosuki will grab your favorite bands from them. Or if you’re old-school, and all your music is on vinyl and 8-track, you can just type in as many of your favorite bands as you want, on that page.

That’s all you need to do. Now Mosuki will include shows featuring your favorite bands in your daily emails, and you can add them to your calendar and share them with your friends just like any other Mosuki event.

As always, send us any feedback, comments, and bugs, and enjoy!

In the early days at Mosuki, Jonathan implemented a table to store “certifications,” which are essentially directed, labeled edges connecting arbitrary rows, or objects. These edges can connect any two rows in any of several different database tables. And this power lets us implement major features that we didn’t plan for originally, like adding iCalendar feeds, discussion forums, scenes, places, and a myriad of object-specific user preferences to the site, with a minimum of schema restructuring. Often we can add whole features without touching the schema.

This table is also the largest, and most problematic speed-wise as it requires two joins instead of one (although Ross has got it pretty much under control now), which I think speaks to the original article’s point that relational databases aren’t the best choice for more free-form applications.

There are two privacy mistakes here. The first, as Scoble points out, is the absence of full-featured, granular privacy controls. It’s a mistake to assume, as Google did, that sharing an item in a collection and sharing the entire collection are the same proposition. It’s also a mistake to assume that sharing an item in a collection with a person is the same proposition as sharing the entire collection with them. Many web calendars made the same mistake early on, allowing their users to control the sharing of calendars but not of individual events.

The second privacy mistake is to ignore the discoverability of public data. Facebook made exactly this mistake in 2006, when they decided to aggregate all the changes that were made to your friends’ profiles, and show you those changes on your Facebook home screen. Everything they were aggregating was technically public information from your friends’ profiles, but people screamed bloody murder. The same thing happened with Google Reader; although the shared items were, technically, publicly accessible via obfuscated URLs, the only way to visit one was to receive the URL from a friend. The new sharing feature radically changed their discoverability.

When a piece of data is practically undiscoverable, users treat it as non-public. When that item’s discoverability is then increased, users react as if their privacy has been breached. (This is actually the flip side of security by obscurity, where a program assumes that undiscoverable means private. The reason software makes this mistake is because people do.)

Mosuki has had full-featured, granular privacy control from the beginning. And it lets you control both how easily your friends can discover your group-only events, and how easily anyone on the internet can discover your public events. And these are features that can, and should, be applied to any system that involves sharing potentially privileged data. Sounds like Google Reader users might like them.

The founders of Mosuki have always believed that providing a service for other people to use means taking on the responsibility to fix bugs and make sure the site is available — regardless of being “beta” or free of charge.

Enjoy!

If you’re reading this blog, chances are you dig Mosuki, so do us a favor and visit the review and vote for us by clicking on the “killers +” button at the top right. Lower down on the page there is a poll where you can vote for whether you think we’ll “Go IPO,” “Get VC,” and other outcomes. I’m disappointed that they left off “Total world domination,” because that’s obviously where we’re headed.

We’ve also improved event, scene, and place lists to show thumbnailed images from the event, scene, or place description. You might already know that if you have posted an event, scene, or place that has a poster, flyer, or logo, you can put a URL to the image into the description. The image will automatically show up on the page once you save the event, scene, or place. And now it will also show up as a thumbnail, on the event list on your profile, and on the main event, scene, or place lists.

Stay tuned! More improvements coming soon.

What do you need to do to take advantage of this? Just make sure your zip code on your profile is correct, and when you enter a new event, make sure you use a place with an address, zip code, or city and state.

Do you want to know what’s going on in a new city when you’re traveling? Just change your zip code on your profile (and remember to change it back when you get home.)

As you might expect, this new feature required more under-the-hood changes than most updates, and the release has its share of bug fixes and minor improvements. But we won’t bore you with the details — why don’t you find a cool event and go to it instead?