Twitter

Twitter sign-in is active, although we are still keeping this on the low. Today, a Twitter bridge was enabled which allows existing users to connect their twitter accounts and send ActionStatus updates (or any update) to their twitter account. Reachable on the dashboard.

Lime

Lime derivation from the Melative core is still currently under heavy development. Just as the derivation of the entire Nuclear api kit came out of Melative for open-sourcing, so will LightMeta. This is one project offshoot we have high hopes for, as it has proven very useful in creating an open, categorized/typified library based on media-types, but that’s not to say it is restricted to any typing specifics, and that’s the kind of light organization that makes it useful.

Kronblr

Kronblr, the federated micropublishing platform, hit version 0.1 early in the year, and we are still looking to push to 0.2, which will include some square revisions. Integration of Kronblr with Melative is presently stalled, as we look for options on structuring the ActionStatus format.

ActionStatus

ActionStatus is what we’ll be calling the format birthed from Melative action-updates, or textual scrobblings. ActionStatus has similarities to the increasingly popular ActivityStreams specification, and we want to make it as easy as possible to transform ActionStatus updates into ActivityStreams format.

Some might question why we don’t use the ActivityStreams spec and end there, and the answer is that ActivityStreams has limitations in comparison to ActionStatus. ActionStatus, for one, has no verb limitations and a format which fits better with Lime entities and attributes. Secondly, ActivityStreams is an Atom extension, and we do not use Atom as a native API format. Having a similar but slightly less specific format offers the advantage of maintaining native API structure with simple conversion to Atom when necessary.

Nuclear

Last but not least, Nuclear deserves a mention as it is largely what makes it easy to hack on Melative. Nuclear has seen good changes since Autumn 2009, many of which have enabled it an abstract federated core. This means that Nuclear can store users and social relations between users, regardless of domain. This high-level relation-building is something we believe is crucial for the future of Melative and web applications in general. Regardless of the success in our specification, we feel comfortable opening up to other simple, high-level relation protocols should they grow into feasible solutions.

Nuclear is a fun project to work on, and we have our eyes set on natively integrating some rising protocols such as WebFinger, XRD, RSD, Salmon, and more as the come.

That seems about it for now.

Microblog Parse

In order to make a rating through the microblog, the update must include ‘rating:’ (case-insensitive) followed by a rating. The format for segment rating varies, but the rules are basic.

Rating Format

First, it should be addressed that segment ratings are normalized to a 100-tier system, s.t. 88% = 88/100, 8.8/10 = 88/100, etc. The numbers which are used in the rating do have effects, especially when the /Max is not included.

When /Max is included:
The rating is calculated as Value/Max and normalized to Max=100. If rating 8/10, this will equate to 80/100.

When /Max is not included:
If the Value is less-than or equal-to 10, the base is considered to be Max=10, then normalized. If the Value is greater than 10, the base is considered to be Max=100.

Unless your Max is always out of 10 or 100, it is best to use the /Max for accurate ratings.

Valid Rating Examples:
6/12 = 50/100
5/15 = 33/100
18/20 = 90/100
47/50 = 94/100

8.1/10 = 81/100
3.51/10 = 35/100

Note: If a decimal results, the value is floored.

What is a segment? A segment is a sub-section of a context, or title, such as a track to an album, an episode to a tv/anime series, or a chapter to a book/manga.

Here, I’d like to address 4 aspects of the service to help enrich the understanding of this Federated specification, as well as the solution and benefits it provides.

What problem does Federated micro-publishing solve?

• Social services may only be used with valid usership
• Social relations may not be established without mutual usership (centralization)
• Social services are closed, by nature (one must have an account)
• Social services are centralized (e.g. thedomain.com)
• Users are following other rules (e.g. site agreements)
• There is no freedom, as there are always requirements (e.g. usership)

How is this a unique solution?

• Decentralized (users on any domain may be part of the social-sphere)
• Federated (users may establish relations without regard for central usership)
• It’s a specification
• It’s an open protocol
• It’s adaptable and customizable

We are only implementing a version of what is possible through the API specification. Other developers may create their own platforms which will interact in the same fashion. The aim with Micros is a publishing platform, similar to a blog, but extensible through theming and plugins. The core of Micros will be a hooking environment in which 3rd party scripts may execute.

Is there evidence that this works?

• The Nuclear platform currently supports the core specification
• The specification fully uses OAuth, an established technology
• Runs on any scriptable web host (no req. for full server control)

What sort of business model does it cater?

• No central ownership
• Specification provides an infinite platform
• Open development
• 3rd party applications
• 3rd party features
• Potentially massive user-base (the Internet)

The importance in the business model is that the specification allows developers/vendors to create their own pay/private services, which still enables interaction with the social-sphere. Also open is the area of customizations, similar to Wordpress’s flourishing theme/plugin base.

In summary, we are modularizing the microblog to fit this specification in hopes of building a larger, open social publishing network that may be used regardless of usership and domain.

The microblog on Melative is perhaps one of the most familiar features for users, but with the amount of attention and development that goes in, there must be something more.

What is the Micros?
Micros is a textual interface for micro-updates, which also allows inline commands on context-types, or what we call textual scrobbling. Textual, for the scrobbled update (e.g. ‘listening to /music/Crooked Rain, Crooked Rain/track/Gold Soundz.’) may also have a message appended to the event (e.g. ‘listening to /music/CRCR/Range Life. We should all strive for a range life.’).

It may be seen as a status-update type interface, but there is special nuance between “status-update” and “microblog” (here is a clear explanation which I find handy). When we consider textual scrobbling containing message content, it is much more fitting to be called microblogging than status-update. The key here is “content,” or more specifically publishing content.

At the top level, Micros aims to be more akin to WordPress, in that it allows content publishing, but in a micro manner. This similarity also is aligned with the notion of being open-source and allowing decentralized installations.

Why is Micros important?
As we develop this feature more, we are aiming to extract and modularize it as a standalone application, while still allowing interface commands to have value on the Melative experience engine (organizing, categorizing, interacting with a user’s media library).

At the same time, the system will be built for near-real-time notifications across domains, yes cross-domain following/subscriptions/@replies.

We feel, that in this age of communication, there is little reason to centralize micropublishing to a few large, closed¹ channels (Facebook, Myspace, and Twitter), where there is no inter-channel communication without valid usership on each service.

Simply put, Micros is a blog which will notify subscriptions in near-real-time, without the need for centralization (those who are subscribed on various domain/nodes will receive the content directly).

Notes
1 – Closed in the sense that non-users may not interact, this is the opposite for Wordpress, which allows non-user commenting. Micros will allow non-user following, where the event (an XML packet) is sent to subscribed nodes.
-There are other features behind the system, such as scrobble-anything and exact context-referencing, but they are slightly more specific to the experience engine (allowing logging, linking, rating, tagging, wishlisting all from the microblog).

1) In accounts, select laconi.ca as the service for a new account.

2) Enter name@melative.com for the screen name, where name=your user name

3) Add the account, and hit Connect

4) Enter password, and Login to enjoy

^_^

Notes

For more information on how this works, see the laconi.ca Twitter API documentation. Note: we are not using laconi.ca, but simply built an interface almost to the specifications.

Language

Languages are internally defined using ISO-639 and this originally applied to the title names. Eventually, there will linkage between a user’s language preference and the primary titles that appear on various pages (except on another user’s Experience Library).

A second usage of the ISO languages will be in variations (pages), which we will be able to select the proper page based on language preference. This is nothing new/special and it might be wise to route entire subdomains to various language versions of the site (similar to Wikipedia). It’s still undecided, but the page data will be portable.

Timezone

There are only a few areas which allow custom timestamping, but timezone selection will aid in adjusting properly to UTC. Currently, user-timestamped entries are expected to be adjusted to UTC (or rather, the system does not compensate if the ts is not UTC). This preference is more of a helper function, rather than a feature, and simply adds a bit of transparency to user location.

Notes

Custom timestamping is currently available through Microupdates and setting Experience. All other events should be timestamped to UTC.

if you don’t mind me saying, the principal problem is that melative is competing with many services

primary value proposition being its one-stop shopness, full-service

I understand this, because it appears that every feature which exists on melative, is enabled for 15 major forms of entertainment*, thus competing with the music sites, the book sites, the movie sites, anime, manga, whatever.

This is the wrong focus. Melative, as a whole serves only a few purposes:

• express and catalog experiences on entertainment works
• semi-semantically index meta information on entertainment works
• do it socially [on entertainment works]

The problem is, users go to 5-6 different sites to accomplish the same task; log an experience, note about it, rate it, tag it, and find other works to experience. All the while, melative can and does exactly this, in new and conceptual ways; we’re always thinking of new ways to interact with entertainment media.

The real question/problem is, are users compelled to separate their experiences between mediums? It is rather questionable because, experience is not bound to medium. Once an experience has become part of the viewer/reader/listener, do we honestly contemplate it as a seprate ‘kind’ of experience? Is there any need to do so?

A great album. A great book. A great film. A great manga. A great opera. A great …

Experience is Boundless

Melative is about the Experience.

Notes

*Is this arguably not a benefit?
Entertainment works, should generally not include ‘Events’, but as with entertainment, arts and events, such as competition or live experiences, still provide an experience.

1. New front page layout and information
2. Creator/Character pages (via search and relation)
3. remove.association API method
4. Stream extension bugs (0.1.4.8)
5. User statistics on /timeline
6. Insert tracking (partially the additions API method)
7. Variation data/field sizing (which titles are most complete)
8. Cron jobs to remove invalid @replies
9. Apply new stream parsing class
10. Reflections view (similar to associations)
11. Stream item editing (context, timestamp, message)

Various involvement level, but I’m terrible at judging what to do first versus what will accomplish the largest gain. So let’s see if we can be vocal. Some of the more important issues are items 1, 4, 7, and 8, because they affect currently operating methods (although a front page is needed for aesthetics… important, but I’m terribly inefficient. New items would be 11, 9, 5, 3, and 2. These tend to take the longest time because they lack API methods and the interface (having a method makes things quicker). So what’s left? Items 6 and 10, both which have existing methods, but need interfaces.

Now let’s take a look at the important ones, in terms of time-consumption (I’m sitting here wasting time writing this.. lol).

• Front page: This will take a while given that styling is not my forte in any situation (even if my life was on the line).
• Extension: I actually enjoy this, and though development goes very quick, there is a tendency to over-progress for the good of time. Still, these are quick fixes.
• Data completion rating: This would be 1-2 days for the proper db scheming, but it only requires GET methods. Given this would be useful for editors, I’m sure they could work with a very basic XSL overlay (hopefully).
• Removing phantom @: Right, this would be rather quick, since it is all in the DB and there is no need to have proper classes etc to perform maintenance (nothing would get finish otherwise).

Taking care of @replies, the extension, and the front page seem to be the most immanent and reasonable on time.

Updated 2009 Aug 28: crossed items which have been taken care of.

So what is the problem with scrobbling on melative?

1. Generally, while we may be competing with sites like Last.fm, development sees no advantage in competing with scrobbling. If you like listening to music, we advocate Last.fm, but if you like expressing how you feel about music, you may enjoy melative’s textual scrobbling. In short, scrobbling is thoroughly developed elsewhere and information resulting from scrobbling is available through APIs.
2. Scrobbling is quantity based, and therefore must be assessed on the basis of popularity and favorites, rather than the focus of quality. The albums we experience most often, are generally not the ones we have the highest regard for. Melative is about assessing quality versus popularity, though popularity is addressable in similar ways.
3. For music, scrobbling is quite fitting, but when we take into account the 15 other forms on melative, quantity loses meaning. Thinking about the experience of art, theatre, or events, expressing more than one encounter does not add value to a user’s experience profile; experiencing a work once is often sufficient.

And what of textual scrobbling, where lies the advantage?

Textual scrobbling is a matter of expression through actions and words. While experience may be implied, there is an accompanied assessment either through simple actions or reflective sentences within the textual scrobbling event. This is perhaps the major intent of the melative stream, though fully, it is intended to provide a consistent method for interacting with works of art and entertainment.

What we want

Single-item visibility toggles allowing users to set an item visible to a given set of users or group. On top of this, we want users to have default preferences based by the 14 media, creators, characters, and possibly when replying to users.

Suggested Visibility Modes

everyone

update can be seen by anybody in any stream view

user

update can be seen by all users in any stream view

follower

update is only visible to followers (1-way friends)

friend

update is only visible to friends

hidden

update is visible to friends, but not displayed on their stream view

locked

update is not visible to any other party

group

update may be public, but only displayed in the group view

Now we can see that group posses a problem, since the user may wish to have the item posted only to a group, but not viewable in their public stream, or the group stream view. What this allows is that friends within a given group may share updates without joining the entire group stream. (This would require the friends be part of the given group)

At this time, there is no integration between the friend stream view and group views. This may continue as two separate views; the user viewing all or one of the groups to which they subscribe and the user viewing their friends’ activity.

It is necessary to mention the default user preferences when they post. Given the 14 media, creator, and character contexts, it is possible to set the default visibility per context-type. A user may have all their events visible by default, but can specify certain contexts to be friends-only or entirely private. In this situation, the default preference should be submissive to an override field in the action/announce API methods. Thus allowing select items to have a visibility outside of the user’s prefs.

I like it. Now writing the backend to change a user’s updates when they switch preferences will not be fun for the db, but it’s entirely doable. It should also be noted that the user needs the ability to change stream item visibility at will, though changing from public to private will not be advised since the visibility may still exists through feed caches or other node subscriptions.