Recent Updates Page 2 RSS Toggle Comment Threads | Keyboard Shortcuts

  • tikva 4:59 pm on July 26, 2011 Permalink | Reply
    Tags: hackathon, locker project, QS, quantified self,   

    The Locker Project’s First Hackathon, EVAR! 

    The Locker Project recently had its very first hackathon at Singly’s headquarters in San Francisco! Nearly 30 developers in the Quantified Self community came out, passionately hacking their way through Locker Project goodness. I speak on behalf on the entire Singly team when I say how appreciative we all are for the loving attention the Locker Project is getting.
     
    The hackathon was super exciting for me and the entire team, working with so many excited developers. We had a ton of fun over beers, tacos and cupcakes, thanks to Cups & Cakes Bakery!
     
    http://www.flickr.com/apps/slideshow/show.swf?v=71649
     
    We learned a bunch about what’s working and what can be better, which we’ve taken to heart. As people went through the process of installing lockers and building connectors and applications, we discovered install issues we weren’t aware of and needs for documentation to make building easier and quicker.  The team took the feedback to heart and has been working on documentation on the wiki and tarballs that come prepackaged with all dependencies intact!
     
    Here are some examples of what folks worked on during the evening and since:
    • Leonard Lin worked on a “geo viewer” application to get his contacts onto a map so when he visits a city, he can see on a map who lives there along with how to get in touch with them. He used the Locker Project’s Contact Collection to pull in his contacts along with the FourSquare Connector to pull in latitude and longitude for each contact and draw markers on his map view. He said he had to “blindly” go through the Contacts Collection to figure out what the geodata was, which was difficult. He said he wants geodata to be a first class Collection and so do we, so we are working on this!
    • Steve Lloyd worked on building a Connector for Dailymile.com, which is where he gets his running workouts. He wasn’t able to get the Connector to sync data, but he does have it authenticating and pulling data over at: https://github.com/repeatingbeats/Locker/commits/dailymile. He’ll be sending a pull request once he’s complete with it!  Steve does pretty heavy work in Node.js/MongoDB in his day job, so didn’t have problems getting started with the code. However, he did find that getting started on a connector was somewhat difficult. He said our documentation is very good in terms of what files we provide, but still thinks our documentation is light on concrete examples for common patterns such as syncing data, storing data, and passing events. He says he knows he’s supposed to do those things, but he doesn’t really know why (beyond the basic premise of the Locker Project) at this point.  As a result of his feedback, we’ve created a step-by-step “How to create a Connector” using FourSquare as an example which can be found here: https://github.com/LockerProject/Locker/wiki/Create-a-new-connector.
    • Paul Oppenheim spent time porting Slackulator, an application he had already made, over to work on the Locker Project. Slackulator tells you how many minutes per day you would waste (er take) to keep up with individual people you are following on Twitter. He was able to pull tweets in and was hoping to get to process them service side and then draw data once stored by got stopped.
    • Sjors Provoost built a WakeMate Connector. He said the skeleton code was hard to work with, because it was too closely tied to specific ways of doing things (like connecting to APIs and dealing with OAuth). He got far enough to submit a pull request containing his WakeMate work.
    • Jaisen Mathai: Tried to make a repository viewer for Github’s commits and diffs. They got confused because there isn’t a repository Collection so had to go to the Connector. Said it feels like you should never query the Connector directly, and that you should always query a Collection. It’s fine to get data from connectors in the absence of a collection, it’s just that collections are the preferred.

    Here’s a Twitter list of some of the people who attended. The Evenbrite page has a full list of folks too.

    Finally, the hackathon went so well, that we’ve decided to have them monthly, so please keep your eyes peeled for news about this!

     

     

    • smurthas 5:30 pm on July 26, 2011 Permalink | Reply

      Thanks everyone for coming! It’s was really incredible to bring some of the community into our physical space. The feedback everyone gave has been invaluable in preparing Lockers for OSCON this week. Can’t wait for the next one!

    • mistermister 2:56 am on July 30, 2011 Permalink | Reply

      The link to dailymile.com link actually points to dailymiles.com which is a parked domain (ad site) not the place you want to be sending people.

    • Tikva Morowati 6:23 pm on August 1, 2011 Permalink | Reply

      Mistermister, thanks! It’s fixed!

  • quartzjer 1:50 am on June 16, 2011 Permalink | Reply  

    Locker Arch in a Nutshell 

    We’ve had some various pieces of the overall architecture documented both in the codebase on and the wiki, but I thought it would be good to refresh and highlight the overall design here and have a new living master copy in the wiki.

    The locker is a bunch of web services that all natively speak REST and JSON to each other, all independent but connect to each other via one core web service, lockerd.js.

    The core service:

    • Installs services
    • Starts/stops any service
    • Manages how to access any service
    • Passes events (push) between services
    • Schedules upcoming task/job callbacks

    Individual services themselves are designed to be very isolated and loosely coupled:

    • They are started in their source code directory
    • They are provided a single persistent working directory and localhost port to listen on
    • Their working directory is for any stored state and data files
    • Any “session” information is passed via STDIN on startup from core
    • They should be be able to be turned off/on safely as needed
    • Any interface and controls for the locker owner are via html5 served on /
    • They always live behind a reverse proxy (core) that manages access
    • All access is via straight HTTP, as services within a locker may be spread out across devices, computers, and cloud instances

    Now, in order to know what services are providing what functionality and data formats, there is a concept called “service types” which provides a definition of:

    • One or more REST calls
    • The structure of the JSON data returned (attributes, values, etc)
    • Other data types returned (thumbnails, files)
    • What events are generated and their structure

    Examples of service types are like contact/twitter, contact/gmail, photo/flickr, status/facebook, etc.  Any service within the locker needs to define what types it provides, and can ask core how to reach or listen to other services based on their types.

    That’s pretty much it for the fundamental architecture in a nutshell!  That’s only part of the story though, very important is the common patterns that have been evolving around this architecture that most of the services are using in some form:

    • Most of the services are very event driven and written in node.js, and others in python (but as above, the arch is ultimately language independent)
    • The three general role patterns are services being either a:
      • Connector – to external data source
      • Collection – aggregation of common data types like photos, contacts, etc
      • App – functionality built to experience/manage data from Connectors/Collections
    • Some of the services with larger datasets are using Mongodb for lightweight indexing
    • Any service syncing/archiving data should store it as simple JSON on disk for future accessibility

    That’s where we’re at so far and I’m sure it will continue to adapt, grow, and mature as more and more data starts flowing in and ways to make it awesome spring up.  On the near horizon is also patterns involving TeleHash and interconnecting lockers, and making them easy and portable to be run anywhere.

     

  • thelockerproject1 9:01 pm on June 10, 2011 Permalink | Reply
    Tags: TechUpdate lockerproject   

    Tech Update 6/6 – 6/10 

    It’s update time and we’ve been working hard so let’s dive into what’s been done this last week.

    Release 0.1.0

    Another milestone reached and we’ve tagged a release! Release 0.1.0 is focussed on a complete bottom to top stack, for Contacts, that starts to define correct development patterns. All the work from the last tech update has been pulled together and as a quick summary here are some of the big changes:

    • New look for the dashboard
    • Data store integration, starting with Mongo
    • A data query system
    • A new merged contacts viewer app
    • Cleaned up connectors
    • Bottom to top data flow for Contact data

    Developers gain the most from this release, getting a much clearer picture of how the system is supposed to work. The Merged Contacts Viewer gives a real world app on top of the data and using all of the correct APIs.

    This release also ushers in a more end user friendly system. We’d love everyone to start using this and giving us more and more feedback so that we are truly creating your Locker.

    Testing Updates

    Post release has seen a lot of work around testing. We’re working on more coverage, simpler tests, better tests, and more. Also, we’re setting up a continuous integration system so we are constantly monitoring the status. Expect notices from it to show up in IRC soon.

    Virtual Machine Exploration

    Virtual machines have been in our heads as a vital part of the Locker Project since the start. Being able to isolate data, potentially running services in other places, or even relocating your Locker, are just a start of the reasons we’ve been thinking about VMs. We’ve begun our early investigation, playing with Xen instances that are hosting LXC instances inside of them.

    We hope that this exploration will lead to us offering developers space to use lockers in soon.

    New Connectors

    We had a slew of new connectors come up this week so here’s a short rundown of what we got.

    • Dropbox: Stores and retrieve files from your Dropbox account. The first of a few connectors that explore data store like connectivity.
    • Twitpic: Syncs photos posted to your Twitpic account.
    • FitBit: Syncs data from your FitBit account.
    • Simple Journal: Store and retrieve user pushed basic JSON objects with a timestamp. Check out the Blood Pressure Tracker app as an example of using it.
     

  • quartzjer 2:03 pm on June 6, 2011 Permalink | Reply
    Tags: Trust   

    Tenets of Digital Trust 

    Since one of the most important long-term goals of the Locker Project is enabling a more powerful sharing platform between people (interconnecting Lockers via TeleHash), I’ve spent a lot of time thinking about the fundamentals of sharing and communicating online, and it always seems to come back to one intangible concept: Trust.  I’ve been breaking this into more traditional components to understand them better and wanted to share these ideas about the tenets of *digital* trust, which has real-life trust analogies but also more complexities being online.  I like to apply each one of these to any ditigal system to help guide my understanding of how it creates trust:

    • Authenticity
    • Verifiability
    • Security
    • Transparency
    • Consistency

    Authenticity is essentially the digital identifiers that are associated with someone and the confidence in whatever system generates those identifiers, that they represent the same person when repeated.

    Verifiability is the degree of your ability to establish the authenticity of someone, either actually in person or via another trusted person or system.  It typically precipitates and helps build authenticity, and comes into question when something unexpected or important happens.

    Security is the confidence in the integrity of the computing system both that you’re using, and that the other person is using.  There’s less trust when using public terminals or if suspicious dialogs happen on your own system, and equally so you wouldn’t share something important to a friend who’s using a possibly compromised system.

    Transparency is all about user interface and messaging, it’s how clear and consistent the tools and dialogs are in communicating what is happening.  It’s about creating complete expectations and delivering within those without trying to hide anything.

    Consistency is the complete experience over time and the most obvious one. Fundamentally, does the interface and do the identifiers create a predictable pattern that build confidence in someones digital experience.

    Since this is just a snapshot of my current thinking it’s likely to evolve and change as I try to apply it to more and more online experiences (like, is Security really worth highlighting on it’s own, or is it just a consequence of the others?).  For now it’s been a very handy way to tease apart some of the complexities of digital trust as we build the learnings into the foundation of the Locker Project, aiming to do a great job at connecting people with their data and better empowering them to share safely with others.

     

    • mushon 6:41 am on June 10, 2011 Permalink | Reply

      One more “tenet of *digital* trust” for you to consider:Confidentiality is the ability to make sure my shared data aimed at a specific social context is not compromised by leaking outside of that context. The malleability of digital data obviously makes this a hard task, but there are ways to create a culture of confidentiality (people don’t build Twitter robots to retweet private accounts, even though they can) and I believe that needs to be baked into the core of TLP.

    • messageTH 10:39 pm on June 28, 2011 Permalink | Reply

      Like this post. Thanks for sharing. How bout adding this to the elements needed for creating trust? Community is created when you consistently act to show that you have an interest in engaging in 2-way dialogue with me. This lessens my fear that you’ll take advantage of me and leave.

    • smurthas 12:03 am on June 29, 2011 Permalink | Reply

      Both are excellent points. Confidentiality is closely tied to Security and Consistency, but stands on its own as well. Community is hugely important and (among other things) acts to reinforce Verifiability, Transparency, and Consistency.

    • Fellow Traveler 10:45 am on July 4, 2011 Permalink | Reply

      Is the data inside my locker encrypted?Is it possible for Apps to have private data, that other Apps can’t access?How do I selectively give access to a 3rd party to SOME data, without giving him access to private data?Just wondering on the specifics of this.

  • quartzjer 4:04 pm on June 2, 2011 Permalink | Reply  

    The First of Many 

    I’ve been meaning to get a tech update out for a while now, but we’ve just been so busy!  I know, it’s a terrible excuse.  We’re an open source project and I feel we owe a bit more transparency.  That said, I’m going to do my best to try and make this a weekly update.

    Let’s get on to the news.

    Logistics

    A few up front logistics items.  We’ve moved the project to an organization page and repository.  We can now be found here.  You can either reclone your repository or change the origin url.  Jump on IRC if you are having issues with that.

    We are merging our previous dev branch into master permanently.  Too much of our work is hidden without some digging because we focus on the dev branch currently.  This has also led to confusion for testers as they run and then submit issues against the generally older master branch.  After the merge we’ll continue operations as normal, only spinning branches for larger changes and point releases.  Tags will be the primary method to track individual versions.

     

    Data Store

    The question of a backing data store for the system has come up many times, and we’ve finally settled on MongoDB.  All our core Connectors and Collections are starting to use it with great results.  Fear not for your simplicity though, one of the goals that we’ve had is to store data in a very basic and historical manner as well.  To do that Connectors maintain a simple disk based JSON file of all their synced activity.  This allows the Connector to easily reproduce current state if we need to change design goals, as well as provide you, the user, with a complete and simple backup forever.

    Another important point is that the use of Mongo does not preclude other data stores.  The Locker is an evolution with data and one pattern can not be used to reflect all data out there.  We will highly suggest that people try and use the existing Mongo, but if a new data set truly does not work in Mongo we’ll definitely help work out integration of other data stores.

     

    Query Interface

    Now that the data is accessible in a more common and powerful manner (read: Mongo), it’s natural to want to query into that data.  We’ve made a first pass implementation of a query API.  Most of the parts described in *Core Locker Data Access API* are implemented and available at the /query endpoint of the core.  This is an area we know needs growth and more iterations so I encourage you to play with it and come help us make it better.

    Dashboard

    The new dashboard look and feel is in from Justin Mecham.

    Screen_shot_2011-06-02_at_10
    Screen_shot_2011-06-02_at_10

    See the full gallery on Posterous

    This is definitely a step up and we’ll have a lot more coming in the user land soon.

    Wrapping Up

    All of the parts we talked about here, plus all the other work under the hood is being quickly wrapped up for a new release.  This is an important release because it has a more unified stack, as well as a more user friendly interface.  We’re still a bit more focussed on developers, but we’re getting really close to general use.

    We’re tightening up and moving faster, so keep watching for more updates!

     

     

    • jsmecham 4:10 pm on June 2, 2011 Permalink | Reply

    • ctide 5:18 pm on June 2, 2011 Permalink | Reply

    • Zooko 6:59 pm on June 2, 2011 Permalink | Reply

      “The question of a backing data store for the system has come up many times, and we’ve finally settled on MongoDB.”Is there a public record of the discussion?Regards,Zooko

    • Thomas Muldowney 9:35 pm on June 2, 2011 Permalink | Reply

      The conversation started at the earliest stages of the project and to be honest Mongo was in an early lead due to comfort from the core people that had used it. Most of the conversations were held verbally and not recorded. Later we decided to architect things so that we weren’t bound to a specific data store system, and I did a quick pass of testing basic operation of a few systems and we ended up looking at Mongo and Couch. Both seemed fine, but the comfort level was higher on the Mongo side. A few conversations are captured in the IRC logs, but the community is still getting active and the initial choice was made to use Mongo, at least for collections some of the core people are actively working on, with a door left wide open to doing others or expanding.

  • quartzjer 7:41 pm on May 16, 2011 Permalink | Reply  

    Brainstorming TLP Core Values 

    I’ve been wanting to share the core values that both inspired the founding of the Locker Project last year and that are driving me so passionately to advance it, but it’s been challenging to summarize such things.

    The first and most central value is that of personal data ownership.  That may not mean much to most people, but let me try an analogy: it’s been tried often in the past to create micro economies where you get paid by an employer in company “credits” that are useful only at the company store, you never really owned your paycheck/money.  I feel like that’s the world that we’ve fallen into when it comes to our personal data, and anything we can do to have more ownership over our data will free us to create a more vibrant digital economy.

    Now, it’s not enough to simply own (or at least have a copy of) your data, it has to be useful to you.  That’s the second core value, the ability to get immediate and direct personal value out of your data.  It’s yours, you should be the first and primary beneficiary of it, and you’ll need an open platform and great tools in order to do that.

    My third core value builds on the first two and is the very fabric and definition of (digital) freedom.  Everyone must have the capability to both share (or not share!) their data and the right to make those sharing decisions without bias.  This one is difficult to summarize but it’s central to any society, that individuals can connect independently and are free to decide to share things between them without any oversight or gatekeepers.

    My first attempt to simplify these into three statements a while back was this:

    • We believe you should have the ability to make a copy of your data
    • We believe your personal data should be always available and most useful to you
    • We believe that you should have have the freedom to share your data however you want

    They weren’t quite right, and the “We” felt like it created a separation, so I refined them further, here’s my current core values draft:

    • I own my personal data
    • I want my data to be useful to me
    • I make the decisions to protect or share my data

    Possibly a bit too far simplified, but they’re a work in progress. I wanted to openly share them with everyone for feedback as well as give some background on my personal drive in building this platform.

     

     

    • Devon 9:17 pm on May 16, 2011 Permalink | Reply

      This is my breakdown of your core values:I = Sovereign IDentity (I)I = Legal Structured Asset (OWN)Data = relational to I on per transaction basis (Data Value)I think you are on the mark in all regards.Its the proper definition of ‘I’ on universal Terms that is holding us back. Without it, ‘you’ and ‘me’ are distinctly un-relational, and data is managed in unpredictable ways with a loss of transactional efficiency.You can define and trust ‘I’ for you. But you can not service ‘I’ for me on those same Terms presently. Without I & I being systemically equal, their is loss in the system caused by the distortion which is being leveraged against I’s everywhere…all the time.

    • Miten Sampat 12:21 am on May 17, 2011 Permalink | Reply

      Thanks for starting this effort Jeremie, it is too important a problem not to try :-) the three pillars of your thinking are spot on. at the same time, in protecting ones data, it is important to realize the tremendous value each of the platforms give you (in terms of content, services, and personalization).the right answer here will ensure a balance between the need for services to leverage “aggregated data” generated by consumers to make their services better; and one that allows consumers a mechanism to transact specific data on a case by case basis and enforce their rights when they want.fascinating times. PS: i look forward to seeing you at PII 2011

    • Francis Fallon 11:47 am on May 17, 2011 Permalink | Reply

      The only thing that I would add is, and maybe this seems inherent already but, words are powerful-I want MY data to be MOST useful to MEor,I want to HARNESS my dataTo me at least, it’s more than just about ownership and control – it’s about ACTIVE empowering. Leveraging data should do more to benefit each of us than any one else. In my opinion, it’s about being in the drivers seat with my foot on the pedal and my hands at 10 and 2, not just owning the car or the keys.Jeremie, I am not a computer guy- just an advertising strategist very passionate about this cause.When the time comes that you need help getting word out there about this, I would love to champion this cause and join your team should you ever need a loud mouth.Thanks.

    • quartzjer 12:14 am on May 19, 2011 Permalink | Reply

      Thanks for the great feedback from everyone, it’s so exciting to know that many others feel the same urgency and dedication around this kind of model :)

  • temas 7:37 pm on May 6, 2011 Permalink | Reply
    Tags:   

    Where Does My API Come From? 

    A lot of people step up to the Locker Project and are immediately looking to start using the data stack to create an application. I’m super excited that people can see the vision, and want to build on top of it, but it’s not quite there yet. With some effort the steps to start pulling data, collecting it, and then build on top of it can be figured out, but it’s far from intuitive or uniform. Once someone gets a working system the next question is, “How do I use this?” or, “Where is the API?” It can definitely get confusing quickly, so let’s pull back the layers, a bit, and start to see where the API exists.

    One key point to keep in mind while reading this is that internally all of the services are normally communicating via REST + JSON. A few exceptions will be mentioned below.

    The Layers

    The first piece we need to ponder is how we represent service data in a general way. In the Locker Project we use a mime-type like system to document the services. There are higher level primary types such as message, photo, link, and contact. Under these are more specific types that usually represent an external service, or a new complete data structure. Examples of currently used complete service-types are contact/google, photo/flickr and link/chrome. Each service-type is a definition of a set of REST endpoints, the JSON structure they return, and the JSON structure of any events generated.

    Bottom up we start with the Connector. The Connector exists to sync data from other sources into your Locker. Retrieval should collect as detailed and complete a set of data as possible and store it in a historical archive. This data is a service-type, for example records from the Google contact manager would be contact/google. Each service-type will have a document describing the details of the information that are stored, attempting to keep as much of it represented by JSON as is feasible.

    Based on the primary type of the data (the “contact” in contact/google) we can begin to expose an API to the Collection and App layer. Every primary type will have a document that states what API endpoints a Connector must expose. For example a contact type might require implementation of a /getAllContacts that would return a JSON array of all of the contacts, in as complete a JSON representation as possible, the Connector has found. There might also be a /getContactById that would return the complete and detailed information of the complete type, as documented.

    These documents will also describe the JSON properties that are expected to be found in events generated by the Connector. To continue our contact example, we could imagine that the document would require the JSON object in a contact/google event to have the properties fullname, email, and number. The event should still send as detailed of an object as possible, but these properties would be required for further use and understanding.

    It’s important to note that a single Connector could potentially handle multiple service-types, so it would need to implement the defined API for all of the types that it provides.

    The next layer up is the Collection, and is the main processing layer of the stack. Collections use the exposed Connector APIs and events to watch for a given primary type and then process it. The collections attempt to collate, dedupe, and generally aggregate as much as possible of a single primary type. Throughout this process they maintain as much of the complete data types from the Connector level, as possible. Collections also maintain the ability to know where the data came from and back track it to a specific Connector and object id so that any lost or extra details can be retrieved. This aggregated data is then saved in a more dynamic and queryable data store (To be expanded upon in another doc). The Collection can then expose the data in as many meaningful ways as possible. This could be a simple /getAllContacts endpoint, or potentially even an interface that is a complex query against the data using something like the Mongo style syntax. These endpoints would be documented in the primary type API document.

    The final layer, the Apps layer is the simplest in terms of API. They are API consumers, using primarily the Collections to get data for user interaction. They might need to go back to the Connector level if they know of a more specific piece of information that wasn’t carried through the Collection layer. The focus here is interaction, you might find yourself starting to create a new data type based on how the user interacts with the data, or perhaps what the user creates in this app. At that point it’s best to consider creating a new Connector and Collection then refocus the App to the user interaction elements with that new stack.

    So Where’s the API Again?

    Hopefully this illustrates that there are different levels of API access for the different components of the locker. The API endpoints are defined first by the type, and then the service that is using that type. Each type will get a document in the docs directory containing all of the arguments, returns and expectations.

    Sounds like we really know what’s going on here! Well, we have a good design concept in place, but all the development work is still underway. Our Connectors and Collections are currently a prototypical evolution of disparate APIs and use cases, with most things hardcoded to just work until we update the internal architecture as we learn from each implementation. The next big development push focuses on these areas, though, and we need help! We need your input to help shape the APIs and developer usability of the system so jump into IRC (freenode #lockerproject) and get in on the conversations as we grow!

     

    • Tikva Morowati 9:33 pm on May 6, 2011 Permalink | Reply

    • chiefwalker504 2:23 am on August 15, 2011 Permalink | Reply

      If you need to read reviews before picking a contractor or auto transporter go to tierads.com, transport reviews,auto transport reviews,auto relocation reviews,mover reviews,auto transport,car transport reviewsandcar haulingandvehicle shipping.

    • Trent Larson 9:29 pm on March 31, 2012 Permalink | Reply

      I found this post looking for the API into my own local deployment… I want get data in and out of my own localhost. I just found what I want: it’s the “push” API here: https://github.com/LockerProject/Locker/wiki/Push-API

  • thelockerproject1 12:57 am on May 6, 2011 Permalink | Reply  

    TLP Presentation at #IIW 

    Jeremie Miller delivers a TLP presentation at Internet Identity Workshop conference in Palo Alto.

    Iiw_photo

     

  • thelockerproject1 12:02 am on April 30, 2011 Permalink | Reply  

    Welcome to the Locker Project :: TLP 

    As we go through our lives we create vast amounts of data about our actions, interests, intentions, communications, relationships, locations, behaviors and creative and consumptive efforts. Our emails, phone calls, social network posts, photos, utility bills, text message records and further innumerable sets of data are born out of the regular course of our actions. Even those of us who aren’t engaged in social media networks create a wide wake of data in their paths.

    Currently, this data is fragmented and scattered. It lives in and is usually owned by the various networks in which it is created or exchanged. It is aggregated by third party trackers and targeters looking to deliver advertising and content to you. It is bought and sold, traded and evaluated, commoditized and valued in a market largely outside the view of the people creating the data in the first place.

    The value in this data serves as the basis for some of the largest power structures on the web, and in the world at large. Billions of dollars are spent tracking and analyzing the data of various social groups and market segments. Entire industries are built on the foundation of this resource.

    For all the power and money tied up in this data, and all the industries built around it, the people who have benefited least from this ecosystem are the very people originating the data. Often times, in fact, the channels and organizations that host or publish the data created by individuals go out of their way to limit the ability of a person to extract their data from the network and own their content.

    The Locker Project and Singly are changing that. Lockers are systems that allow people to collect all of their data into one resource that they truly own. Even the code base of the Locker Project is open source, ensuring that people can run their lockers as they see fit, where they see fit.

    By using a rich system of connectors and collections, lockers make it possible to access and aggregate personal data, even when no traditional web API exists for the source. Interactions between lockers, applications, data and services are encrypted and secured via a highly secure protocol and system of authorization. Singly is working with experts and thought-leaders throughout the industry to provide open solutions to ensuring robust security for these personal data systems. This allows for even sensitive data to be safely included in a locker and made available for a person at all times.

    Data ownership alone, however, doesn’t solve the problem of providing discrete value to a person. To deliver real and actionable value, Singly is extending the Locker Project’s trust and authentication ecosystem to enable application developers to build powerful products on top of personal data. We are looking to solve the parallel problems of developers’ access to and maintenance of personal data and individuals’ needs for data ownership and security, enabling a whole new class of valuable interactions between people, their data and creative developers world-wide.

     

    Digital Sovereignty :: Personal Data + Identity

    We believe people’s data is their own. The Locker Project (TLP) helps people do so explicitly, by providing them tools to synchronize their data into a repository that is owned by them. This data and compute resource (the locker) can serve as a data store, a primary publishing point, and/or infrastructure for applications powered by rich personal data. 

    Additionally, along with being a composite of data, lockers can serve as strong identity components, unifying identities from across a range of services, and providing people with strongly composed identifiers and trust systems.

     

    Persistent + Pervasive Data Access :: Personal Data Lockers

    Many applications and individual uses of data rely upon consistent access to data, and access across the full historical range of data in a given set. Sadly, many data silos are becoming more and more restrictive, making it harder (if not impossible) to achieve this level of access directly through their APIs. Lockers provide a personally-owned data repository that allow individuals to bypass some of these difficulties, and to authorize and authenticate applications on top of this rich data. Lockers also enable connections with non-traditional data types, such as browser history, email records, utility records, etc (at an individual’s discretion), enabling very rare insight into a person’s data profile. 

     

    Flexible Data Access + Manipulation :: Connectors + Collections

    Lockers can provide extensible access to a person’s data via Connectors and Collections. Connectors represent pluggable components that maintain the interaction and sync with external services (Twitter, Facebook, Gmail, etc), while Collections are comprised of logic, data and APIs for abstract data that is composed from other data sources, or synthesized by applications interfacing with lockers. For instance, a Contacts collection represents all contacts from across an individual’s attached accounts, providing a unified mechanism for addressing those data entities. Extending these concepts across various data types provides a very powerful way of interacting with a person’s data.

     

    Open Communication on the DHT :: Telehash

    One of the primary tenets of our projects is that open and distributed communication benefits everyone. Non-blockable communication, free from biased mediation or single points of failure helps to promote dynamic communication and innovation, enabling individuals and applications to change the way they interact around the world.

    Telehash, with its leverage of a Kademlia-based DHT and UDP, establishes a protocol and network which makes distributed communication and interaction much more feasible, providing a unified addressing space and the ability to traverse networks effectively. The more applications that can serve as active switches on the DHT, the more robust and flexible the system becomes.

    Lockers will inherently be Telehash switches, integrating the promise of non-blockable distributed communication with the core of people’s personal data ecosystems. 

     

    Get Involved :: Open Source Participation

    The code for TLP is hosted at http://github.com/quartzjer/Locker, and is actively seeking development and design contribution. There is also an active community discussion on #lockerproject at irc.freenode.net. For more info and updates, follow @lockerproject on Twitter.

     

    Let’s make something awesome.

     

     

  • quartzjer 11:56 pm on April 29, 2011 Permalink | Reply  

    Finally, a blog! 

    There’s been so much happening on the Locker Project lately that we’re way overdue for a community blog :)

    You’re going to find most of the heavy code activity at github and daily discussion around it on freenode in #lockerproject, with project announcements and updates happening on twitter, leaving this blog as a place for anyone working on this effort to expand and share their thoughts and create larger discussions around what we’re building.

    All of us have a big backlog of things we want to talk about here so in-between codeathons we’ll start posting some of that regularly.  If there’s anything you’d like to see just ping us via twitter/IRC, thanks!

    Jer

     

     

Newer posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Follow

Get every new post delivered to your Inbox.