Facebook – A changelog by Daniel Mettler

I decided to disable the “share” button plugin (“tweet”, “like”, “+1” etc.) on this changelog for the following reasons:

I) I have to use (and know about) these social sharing technologies as an IT professional. As a private person however, I disapprove of proprietary technologies that may unknowingly inflict people’s privacy online (for even more scary stuff, learn about browser fingerprinting and read this recent Wired story about undeletable cookies). I also recommend and support using plugins and tools like

Brian Kennish’s Disconnect extension for Chromium based browsers
SRWare’s Iron Browser (a better Chrome alternative, see Iron vs. Chrome)
Tor Project

II) The way how social sharing (and “social” per se) is done today is just plain wrong:

It’s proprietary instead of based on open standards.
Data usually gets pulled into proprietary, closed, data silos instead of giving users full and exclusive control over their very own data.
All the big existing social sharing architectures follow a vulnerable (in so many ways), centralized approach instead of a robust, distributed (or at least federated) one.
Erroneously, people try to solve “social sharing” on the web application level instead of on a lower level and as part of an open protocol and specification (an open social backbone) rather than as various incompatible and proprietary implementations.
Giving users guarantees and full control about their online privacy and data is impossible with the current approaches. Users are required to care about their settings for every single social sharing tool out there instead of being able to specify a global policy (e.g. in the browser).
So far, social sharing is de facto opt-out instead of opt-in, which is the wrong approach if you want to put the user in control and avoid being evil.

III) “tweet”, “like”, “+1” buttons clutter up and “slow down” web pages and make for an unenjoyable user experience, also in regard to accessibility. It doesn’t scale (a separate button for each social network, for each shareable entity on a page , though it’s basically all just about “sharing something”? Oh no!). It’s not even necessary, pure lazyness (feel free to share by copy-pasting URLs manually until there’s a true social backbone). It simply s*cks on so many levels. The “share” button-itis as common today will largely disappear and be replaced by a browser built-in, extensible, standardized social sharing facility in a matter of 5 years.

IV) Do you know the code that hides behind a share button (or a fake thereof)? If so, do you know what exactly is going to happen when you click on it while surfing the web? Neither do I. Security, transparency, reliability, usability and accessibility could be improved a lot by moving “social sharing” from web pages to the browser.

Further (of less importance for the general discussion):

As a private person I don’t care much about popularity contests and popularity in general, neither that of my pages nor of myself (or my virtual alter ego).
On this changelog, the “share” buttons were rarely used anyway. I’m confident people won’t miss them now that they’re gone.

Important note: This post reflects nothing but my own opinion as a private person (like everything else posted on this private blog). I can clearly distinguish between my own opinion as a private person and opinions and needs of other individuals, businesses (even my own business), organizations and customers and fully respect them.

Web 2.0 social media platforms tend to think “big”. They hence often use big integers (8 bytes / 64 bits long instead of just 4 bytes / 32 bits like a normal integer) for user IDs (or sometimes message IDs) to be prepared for even the most extreme potential future growth of their user base. Usually, these big integers are unsigned, allowing for up to 18’446’744’073’709’551’615 UIDs to be stored (which is probably enough to register the inhabitants of quite a few other blue planets too ;).

Facebook, with currently more than 300 million active users, also uses a 64 bit unsigned integer for storing user IDs and expects Facebook applications to be able to handle this. Of course, 300 M user IDs would still easily fit into a 32 bit unsigned integer, but Facebook already goes beyond the 32 bit limit by issuing 15 digit UIDs like 100’000’xxx’xxx’xxx to registered test users (which allows Facebook to better distinguish between test accounts and real accounts).

Now if you happen to use Django to build your Facebook application, this fact needs special attention as Django doesn’t support 64 bit integer field types for its ORM models by default. As a Django developer, you could thus resort to using a CharField for storing Facebook UIDs (which would be odd) or, better, define a custom model field you can use in your models instead of IntegerField. Fortunately, Django offers an elegant way to define custom model fields. You can write your custom PositiveBigIntegerField by simply subclassing (extending, inheriting from) models.PositiveIntegerField:

So, in your models.py add the following code:

from django.db import models
from django.db.models.fields import PositiveIntegerField

class PositiveBigIntegerField(PositiveIntegerField):
    """Represents MySQL's unsigned BIGINT data type (works with MySQL only!)"""
    empty_strings_allowed = False

    def get_internal_type(self):
        return "PositiveBigIntegerField"

    def db_type(self):
        # This is how MySQL defines 64 bit unsigned integer data types
        return "bigint UNSIGNED"

class Mytest(models.Model):
    """Just a test model"""

    huge_id = PositiveBigIntegerField()

    def __unicode__(self):
        return u'id: %s, huge_id: %s' % (self.id, self.huge_id)

(NB: The “Mytest” class is just for testing the PositiveIntegerField definition, it’s not part of the PositiveIntegerField definition.)

Note that this solution only works for MySQL as a database backend (as MySQL supports the “bigint UNSIGNED” data type for columns which isn’t defined in the SQL standard).

For testing, define a “Mytest” model as shown above and execute “python manager.py syncdb” to create a new myapp_mytest table with an unsigned bigint(20) column named huge_id. Register this new model “Mytest” in admin.py, restart runserver and you’ll be able to enter 64 bit integer values through Django’s admin application.

The only minor “issue” is that Django admin’s CSS class (.vIntegerField) used for HTML form input fields representing integer values defines the width as “5em” which is a bit too narrow to display the entire 64 bit integer. This can be adjusted however (e.g. by writing your own ModelForm and telling ModelAdmin to use that, see the Django admin documentation and the Widget.attrs documentation).

P.S. Note that for Django to be able to access and use a “bigint UNSIGNED” data type, you don’t necessarily need to define a PositiveBigIntegerField and adjust your models. Instead, you could simply adjust the column type in MySQL accordingly as a quick-fix. If you use syncdb (like most Django devs) and want it to create your tables and columns correctly however, defining a custom model type as described is the way to go and strongly recommended for consistency and QA.

Tag: Facebook

Django custom model field for an unsigned BIGINT data type