Mosuki blog

In the spring of 2008, we stopped actively seeking funding for Mosuki. We decided then to keep the site up for a few years as a service to our user community.

That was a few years ago. Mosuki will be going down, permanently, on April 15th, 2010. Take this chance to get all of your events off of Mosuki using our iCal feed, and make sure you’ve got current emails or other contact info for everyone in your Mosuki network.

There are a few reasons we are taking Mosuki down. It is expensive to host.  We’ve all moved on to bigger and better things now. Although the site has been up and running without any technical problems for almost two years, we wouldn’t have much time to devote to fixing it if something were to go wrong. And we certainly don’t have the time to keep up to date with everything that’s happening in the social networking space.

We learned a tremendous amount from the process of starting and running a company. We also gained invaluable experience from building the site, evolving it, and working with our users. And we had a lot of fun along the way. We still think Mosuki had a lot of great ideas in it. For a while there, it was a great place to find out about events in the SF bay area. We’d like to thank each and every one of our users for helping to make it such a great community.

I, Matt, will be posting a longer and more detailed analysis of why Mosuki didn’t take off on my blog at some point down the road. And if you’d just like to keep up with the interesting new endeavors we will be embarking on, you can follow us on Matt’s blog or Jeremy’s blog.

Our apologies. Mosuki failed to come back up after a reboot. We’ll have it back up as soon as possible.

Update: It’s back up! Sorry about that.

PotionFactory’s Better Software Through Less UI explains the motivation behind using a little bit of natural-language parsing instead of complex interface widgets. In their case, they built a parser for repetitions, but it was for the exact same reason — quick, easy-to-use UI — that we built a full-blown English-language date-time parser into Mosuki’s event-creation process.

FriendFeed’s new “fake following,” a feature that allows you to appear as someone’s friend without actually recieving updates from them, has gotten a bit of attention from Merlin Mann, Jason Kottke, who calls it “a little bit genius,” and Rex Sorgatz, who calls it “the most important feature in the history of social networks.”

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.

If you’ve wondered why the Mosuki blog has been quiet these last few months, it’s because we’ve been hard at work on what is probably our biggest new feature since we first launched. Mosuki will now tell you when your favorite bands are performing nearby, just like it tells you when your friends post a party, or when a concert gets posted to one of your scenes.

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!

The Death of the Relational Database argues that relational databases aren’t good for applications that may add various additional relationships with new features, because the tables store not just the “objects” but the relationships between them.

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.

Last month, Google Reader started sharing all “shared” items in your feeds with all of your Gmail contacts. If you’d shared, for example, a single item with just your spouse or lawyer or business partner, that item suddenly appeared for all your Gmail contacts. Since your Gmail contacts include everyone you’ve ever sent email to or recieved email from, this ended up sharing lots of items that people would rather not have shared with business colleagues, relatives, or casual acquaintances. One person even complained that Google Reader ruined their Christmas.

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.

Many new members of the “Web 2.0″ smörgåsbord seem to think that by placing the word “beta” in front of their product they somehow relieve themselves of the duty to provide a service which is as bug-free and available as possible.

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.