Das Unwahrscheinliche

Website of Julian Steinwachs

The Ostatus protocol solves the following problem:

  • An update may be represented with plain text in UTF-8 encoding.
  • An update may be represented with HTML.
  • An update may include one or more attached files.
  • An update may be a response to another update.
  • An update can be a forwarded or shared copy of another update. ("repeat", "retweet").
  • An update can be about a topic.
  • An update can be directed to the attention of a particular recipient. ("mention").
  • An update can be related to a location on Earth.
  • Anyone can mark an update as a "favorite", or remove that mark.
  • Users have a unique identity.
  • Users have profile information like name, location, nickname or username, bio, related URLs.
  • Users can be represented with a image ("avatar").
  • Subscriber can receive Publisher's updates very soon after publication. ("Real time", "near real time")
  • Publisher server can store a list of all Subscribers for a given Publisher, including identities and profile data.
  • Subscriber server can store a list of all Publishers for a given Subscriber, including identities and profile data.
  • Publisher server can store a list of all responses to an update by a publisher.
  • Publisher server can store a list of all forwarded copies of an update by a publisher.
  • Publisher server can store a list of all "favorites" of an update by a Publisher.
  • Servers can determine update context and metadata without parsing the plain text according to a particular syntax.
  • Subscribers can subscribe to a feed with multiple authors, such as a group, a search feed, or a tag feed.

This is from the current (10/2012) Ostatus draft. The problem of a social network protocol is hereby dived into two parts. There have to be (publisher) servers which store the content users provide, and there have to be subcribers server which gather the content from the distributed sources into one view for other users.

The first ting that is needed to solve the problem is a ontology/schema/language with which the servers can describe each other what happend. This language is activitystreams (http://activitystrea.ms/). Its describes the content produces by one or multiple users as a flow of activity objects. So the complete data set of the social net is simple one stream of stuff like: "Alice posted lalala, Bob liked Alices post, ..." The language covers a wide variety of things that can happen on social networks, like comments, events, locations, ratings, mood, ...

Because the social net is distributed, this data is distributed, too. Every server (subscriber and publisher) stores some overlapping fragment of the data. This isn't a problem because the streams are mergable as long as the identities are unique. For this reason webfinger (http://code.google.com/p/webfinger/) is also part of the ostatus protocol. This protocol states that your username in the distributed net allways has and @ and then the domainname of the publisher server at the end. So now the stream reads: "alice@somedomain.com posted lalala, bob@otherdomain.com liked the post of alice@somedomain.com"

The idea is that the primary source of the content is the publisher server of the author. If I want to know what alice shared, I go to alices server. But theres is a problem. How should i then know that bob liked alices post if i dont go to bobs server and ask? For that there is the salmon protocol, which lets bobs server deliver the "bob liked alices post" object of the activity stream in a secure way, so that alices server can be sure that it really was bobs intention to like the post. So with the salmon protocol reactions to posts, like comments and likes can propagate "upstream" to the original source. (There fore the name: salmon swim upstream.)

That last important part of the ostatus protocol is Pusubhubub (PuSH) (https://code.google.com/p/pubsubhubbub/) which is simply push for RSS/atom-feeds. So the servers do not allways have to ask wheter there is something new, but they get notified if something happens at the other servers.

One issue that is not yet tackled is privacy, no to confuse with security of identity. Currently the protocol does not describe how to restrict access to content. Currently subscribes don't need any identity. A good candidate for restricting access to web resources is Oauth (http://en.wikipedia.org/wiki/OAuth), which can be combined with PuSH and webfinger. So everytime you subrcibe to some content, the publisher server looks up your Oauth provider through webfinger and triggers the Oauth protocol to probe your identity. If Oauth is completed successfully the subscription gets activated. So now youre publisher server delivers certain content only to those that you whitelisted beforehand, by adding their webfingers to their recipients.

The second issue that is not tackled in Ostatus is hosting of media data. If you want to share a photo in Ostatus you simply share the link to the photo. The problem then again is access restriction. So in the current model you would have an additional media server, like the twitter photo services, where you upload you photo and get a link which you then share. If you want to restrict access to that photo you would have to pair the media server and the publishing server again. Again webfinger and Oauth are good for the job, but the details have to be standardizes.

Ostatus allready covers a fair amount of the functionalitly of a distributed social network, and is extendable to completeness. Because of the splitting of the network in publisher and subscriber, which can but must not be the same, it also provides a full featured API, with which clients (web, desktop or mobile) can be built that are compatible with every Ostatus publisher server. However building on top of that API is much harder than building for Twitter and Facebook. Libraries for PuSH and salmon are not readily available. Writing such a client right now is hard work.

Another chock block are the userbase, which is quite low at the moment. There are a lot of people scattered over several distributed social networks, unable to talk to each other because their developers all had to invent the weel by their own. (http://en.wikipedia.org/wiki/Distributed_social_network) Now they have accumulated truckloads of legacy code, which kind of works, but is not flexible enough to adopt Ostatus easily. Right now they don't have the manpower to make this change. Also the adaption of Ostatus would mean that functionalities get lost, so they are afraid that they may loose some of their userbase on the way.

I can only hope that more developers start using Ostatus for their projects and build libraries and documentation to push the protocol.

Its really a bag of hurt when you try to work on a presentations from different computers with different OS. Google docs issn't any good with movies. Microsoft Office is expansive and two versions of it are of great chance to be incompatible. Open Office has a 20 year old user interface and is damn slow on my mac.

Many of my colleagues use Latex to build pdfs as their presentations, which works quite well if you dont want to show movies, or have any animations going on (i'm not a fan of animated slides). But i'm not very good at Latex and i want to show movies!

So i came up with the idea of using html instead of latex, to do my presentations. First i thougth i'd make one very long downscrolling page and by the way try to question the slide metaphor that dominates presentations today. But i gave up on that and instead built an javascript "application" that can be used to present vanilla-html (the standard tags like h1 to h4 p img and video(!)) presentations.

I didn't come up with a way of abstracting the content from the actual script without using a webserver. Because it should be runnable from a usb stick or a folder from your hdd.

But as a proof of concept it works. I built in some keyboard controlls:

+ : Zoom in

- : Zoom out

a : auto Zoom (makes the slides nearly as big as the browser window)

# : hide the ugly statusbar at the top

and here it is Opera browser currently not supported.

currently supported tags for the slides: h1 to h4, p, table, ul, img, video

 

PS: for presenting in fullscreen i use plainview. It's a fullscreen browser that uses a cocoa safari view, so it works with html5!

Today i came across a problem regarding vertically centering elements in html using css. First of all there are easy ways to do vertical centering:

  • if the parent element of your element has a fixed size (not percentage) than you can use margin: auto 0; to center it. What it does is, that is says to the browser it should compute a margin so it is centered.
  • in a similar way you can use margin-top: 50% - 200px; 200px beeing the half of the height of your element. But this time your element has to be of fixed size.

Both options didnt work for me, although they are slick and i would recommend them if they work for you. I wont get deeper into them.

Then i played around with the vertical-align: middle; option. It only works on inline-elements! What it does is that it align your elements to the middle of the foregoing element.

My solution now is the following. Create a helper div inside the element you want to center in that has 100% height and display set to inline-block. Subsequently you can place your element as an inline-block element that can align itself along the first one without predefining its height, or the height of the parent element.

example with code

As you can see the element is centered, without having to know its height.

Update: I just realized that it doesnt work in opera.

PS: im sorry for comments being disabled. I'm working on it. Meanwhile email me

Deviations: 6. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010

Deviations: 5. Jan. 2010


Warning: mktime() expects parameter 6 to be long, string given in /home/www/web385/html/posts.php on line 40