I've been banging on about this for a while so was delighted to be invited to chat with the GeoSocial Task Force on their monthly call.

But, before I start, please remember that these proposals are not mandatory. If you don't want to share your location, then please don't share your location. This is an optional feature which shouldn't be used by people with a strong need for privacy.

We were primarily discussing the nascent Geographical Microsyntax proposals.

Firstly, I love the idea of being able to share my location. I want my friends to know I'm in town for a gig. I want people to think I'm cool because I'm seeing some experimental theatre. I want to virtue signal that I'm giving blood.

Similarly, I want to be able to find social media posts by location. What's happening right now in Paris? Did anyone else hear that sonic boom in London? Which cool people are also at this gig with me?

But, I do think these proposals have some issues which need to be addressed.

User Research

The primary thing missing from the proposal is any form of understanding what users want to do with a geotagged post.

You see a post like:

Hanging out with friends. I just checked in to Leicester Square.

What do you expect to happen when you click that link?

• See who is at the location?
• Read more information about the place being discussed?
• Find all posts at that specific address?
• Discover posts which are close to there?
• Something else?

What other things do people want to do with geotagged posts?

• Find all posts within 5Km of me?
• Discover users who have posted near me?
• Get emergency alerts for the city I'm in?
• See what's trending in a specific country?

Without knowing what people might want to do with this information, it's rather hard to design a service which meets their needs.

To micro or not to micro?

Where I disagree with the proposals is the idea of using inline text as a form of microsyntax.

Proposals like "I am in /London/ eating ice-cream" or "Checked in to Leicester Square L:N123456" fail for a couple of reasons.

Things like #hashtags and @mentions developed organically on social networks before they were eventually adopted by the platforms themselves. It is rare that a top-down diktat can be used to tell people how they should be formatting their posts.

More importantly, people are crap at formatting things consistently! Every event I go to has people using #Event alongside #Event2026 or #Event26 or a hundred variations.

Even if users could format it consistently, names are ambiguous. Is 🌐:Paris the one in France or Texas?

I'm strongly of the opinion that text is for text, not syntax.

Openness 🆚 Centralisation

Saying that you're on a specific point on the globe doesn't always provide useful information. Even with altitude, it isn't always possible to work out if your in the Starbucks or the Costa next door. Do you want to say you're in a train station, or a distinct platform, or even a specific train journey?

There are various services which offer unique IDs per loosely-defined place.

Google Maps provides a Place ID for every thing that it knows about. There's a similar service from FourSquare. But both of those are closed and proprietary systems - they can only be updated by the company that creates them.

Wikipedia's Wikidata has IDs for lots of places, similarly OpenStreetMap has nodes with names which can be used to identify locations.

But all of these suffer from the same flaw; they are centralised.

If Google kills its service then all those Place IDs die.

This has happened before. Yahoo used to run the Where On Earth IDentifier service but discontinued it.

While OSM and Wikipedia are great projects, they're still centralised. If you're banned from OSM, you can't create a new node.

So, to my mind, the primary way of identifying a place has to use a fully open, globally agreed, and unrestricted standard.

Location Plus Plus

The obvious choice is latitude and longitude as defined by WGS 84. It allows for arbitrary precision anywhere on the planet.

No one can stop you issuing lat/long just because a country is under sanctions. The standards community can't revoke your access to it. The co-ordinates are well understood by almost all software.

There are some alternatives. Google's Plus.Codes build on top of lat/long to make something more human readable. But, crucially, human readability is not the issue here. This is metadata which should never be shown to a human. If a user interface wants to format a lat/long they can do so as a Plus.Code or any other format.

GeoJSON

There are dozens of competing ways to mark up a location.

It seems sensible to me that, given most major social media protocols use JSON, adding GeoJSON would be the simplest way to add geographic information to a post's metadata.

At its most basic, a single "Point" can be shared like so:

{
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-0.13005,51.5103]
    }
}

It can have as much or as little precision as needed.

If the place being checked into has a name, it can also be added - this could be used for display purposes within the message

{
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-0.13005,51.5103]
    },
    "properties": {
        "name": "Leicester Square"
    }
}

The properties can be as complex as the sender wants. For example it could add Wikidata references, OpenStreetMap IDs, telephone numbers, or some cool new thing which hasn't been invented yet.

Here's a maximalist example of checking in to a park:

{
    "type": "Feature",
    "geometry": {
        "type": "Polygon",
        "coordinates": [
        [
                [-0.1303791,51.5099976],
                [-0.1295305,51.5100444],
                [-0.1297077,51.510947 ],
                [-0.1308786,51.5105859],
                [-0.1308893,51.5105793],
                [-0.1303791,51.5099976]
            ]
        ]
    },
    "properties": {
        "name": "Leicester Square",
        "WikiData": "Q848912",
        "OSM": "4082589",
        "GooglePlaceID": "ChIJPcTFENIEdkgR94E58rgB69o",
        "PlusCode": "9C3XGV69+4X",
        "Quinfrob": "🌐89451_𰻝",
        "address": {
            "road": "Leicester Square",
            "neighbourhood": "St. James's",
            "quarter": "East Marylebone",
            "suburb": "Covent Garden",
            "city": "City of Westminster",
            "ISO3166-2-lvl8": "GB-WSM",
            "state": "England",
            "ISO3166-2-lvl4": "GB-ENG",
            "postcode": "WC2H 7NA",
            "country": "United Kingdom",
            "country_code": "gb"
        }
    }
}

What's Next

My personal opinion is that the following needs to happen:

• Talk to some users - find out what they might use this for.
• Work with privacy advocates to reduce possible harms (for example, being able to redact a location from a previously shared post).
• Discuss with developers about how they'd work with this metadata.
• Clients should start adding GeoJSON metadata to their posts, even if it can't be displayed yet.

You can read the minutes of the meeting and I'd encourage you to join the next call.

The one thing it doesn't have is a way to sort your accounts by creation date. I now have over a thousand accounts that I've added - so I wanted to prune away some of the older ones.

So, here's how to do it.

Export your vault

In the desktop version of BitWarden, go to File → Export Vault. Choose the JSON format (this doesn't work for CSV) and follow the on-screen instructions.

NOTE! This will save all of your passwords to disk. Do not do this on a shared machine. Delete the file as soon as you are done with it.

Sort with JQ

Using the jq utility it is possible to search and sort the exported JSON.

This command pipes your export to JQ. It selects all the items, then it sorts by when the item was last edited. It then displays the name of the account and the date, followed by a newline.

cat bitwarden.json | jq -r '.items | sort_by(.revisionDate) | .[] | .name, .revisionDate, " " '

Purge!

You could use the API to delete items based on their ID. Personally, I'd rather go through manually.

What's next?

It would be great if BitWarden allowed sorting by date in their UI. Even better if they could sort by usage. Until then, I'll spend every Valentine's Day manually deleting old and unloved accounts.

It uses C0 Control Characters

Here is an example:

␜
   ␁
      This is a KYLI document
   ␂
      ␝ GroupName
         ␞ data ␟ value
         ␛ Comments are supported too!
         They can be multilined easily.
␙

I've used Unicode Control Pictures so you can see what's happening. In reality, ␜ is  - which on your display looks like .

Why KYLI is 100x better than crummy JSON

JSON is ok, I guess. But it is fragile - breaking if a comma is out of place. It is also really hard to use with text; you either have to escape every " or ' - or remember to HTML encode (and decode) everything. It doesn't have comments. There's no versioning.

KYLI attempts to improve on some of those shortcomings. Here's how it works.

Philosophy

1. Magic characters control the flow of the document.
2. A magic character is terminated by the presence of another magic character. This means...
3. Whitespace is a first class citizen. It can be used in names, values, comments.
4. The only characters which can't be used within names and values are magic characters.
   1. Every other Unicode character is available for names, data, values, comments.
5. There are no "types" - everything is a string.
   1. If you want to use an alternative numbering system, or use ⊨ and ⊭ for boolean, that's encouraged.

Structure

KYLI:

• Will start with ␜ File Separator.
• May have a header - indicated with ␁
  • A header can contain any pertinent information. For example, KYLI version or document metadata.
  • Headers are unstructured. They can hold any valid text (including XML or JSON).
• Will indicate the start of the data using ␂ Start of Text.
• May contain data:
  • A datum's name will start with ␞ Record Separator.
  • A datum's value will start with ␟ Unit Separator.
  • All values are Unicode strings. There is no concept of number types or booleans.
  • Data may be grouped:
    • The group's name will start with ␝ Group Separator.
    • There is no limit to how many subgroups there may be.
• Will end with ␙ End of Medium.

Examples

It is helpful to think of KYLI as a stream of Unicode characters. When viewing a document, you may want to "pretty print" it for your convenience.

Basic

The minimum viable KYLI is something like:

␜␞age␟42␙

Multi-lingual

Names can be any valid Unicode string (that is, which doesn't contain control characters).

␜
   ␁
      Generated on 2017-03-25
   ␂
      ␝ People's names
         ␝ 英国人
            ␛ That's the Chinese word for
              "English People"
            ␝ 123456
               ␞ Name ␟ Terence Eden
            ␝ 789456
               ␞ Name ␟ John Lennon
␙

Which is transmitted as

␜␁Generated on 2017-03-25␂␝Different People␝英国人␛That's the Chinese word for
"English People"␝123456␞Name␟Terence Eden␝789456␞Name␟John Lennon␙

Multiline data easily

␜
   ␂
      ␞ HTML for the site ␟ <!doctype html>
<html>
   <head>
       <title>
      ...
      ␞ date ␟ 2018-01-15
␙

Why this is better

• It discourages editing by hand! You should be using tools to create data or config files. They can verify their validity quicker and more accurately than any human.
• You don't need to worry about escaping "special" characters like "!
• Comments!
• No worrying about data types!
• More compact!
• No bloody commas tripping things up!
• Metadata!
• No confusion over whether something is an object, array, or string!
• Easier to validate!

I am confident that KYLI will supplant JSON in the 1990s pop charts as the preferred data transmission standard of the 21^st Century.

It's as though they think that people won't be able to use a proxy, circumvent the Cleanfeed block, or simply use a search engine to find another torrent site.

Build Your Own Pirate Bay?

Proxying is a very simple concept.

• Alice is forbidden from speaking to Bob.
• Alice can speak to Eve.
• Eve can speak to Bob.
• Alice, therefore, can use Eve to communicate with Bob.

So, a user who wishes to access The Pirate Bay would have to do something quite complex to use a proxy? No, this is all there is to it:

SELECT * FROM html
WHERE url="https://thepiratebay.se/search/ubuntu/0/7/0"
AND xpath='//tr'

This uses YQL and xpath to extract all the information from a Pirate Bay search (in this case, for Ubuntu - which is legally distributed through Bit Torrent).

Simply, this asks Yahoo (an American site) to contact The Pirate Bay (a Swedish site) to deliver information to a user in Britain.

You can play with the results yourself in the Yahoo Console.

This returns a JSON string which can then be easily parsed (e.g. using jQuery). Simple.

Aha! But What About Downloading A Torrent?

In the olden days (well, last year) there was a fly in the ointment. You had to download a .torrent file from the website. That meant that you needed a way to connect to, in this case, The Pirate Bay or find a proxy which was willing to transfer files.

Nowadays, people use the magnet protocol. Here's what a magnet link looks like:

magnet:?xt=urn:btih:fa692da0488aee23e5eb605a87be934ad7cec106

Short enough to fit into a text message and, handily, can be embedded in an HTML document with no need to download an extra file. Paste those 60 characters into your torrent client, and it will connect to the cloud and start downloading the file you requested.

So, a single web request to Yahoo and a line of JavaScript code is all it takes to circumvent this blockade.

Next Move

So, do the UK courts need to order ISPs to block Yahoo as well? Or play whack-a-mole with all the new torrent sites springing up? Let's not forget, in 2004 the huge Bit Torrent search engine Suprnova was sued out of existence. Just like with the Hyrda, a decapitation lead to multiple sites springing up.

Piracy is a problem of convenience. A pirated copy is

• Faster to download.
• Quicker to watch (no unskipable trailers).
• More convenient to transfer to different devices.
• Global availability (no artificial regional restrictions).
• Immense back-catalogue (Star Wars, for example).
• Cheaper.

The only downsides are that they are often of dubious legality, and occasionally of poor quality.

The entertainment industries have to compete on all these points. I'll admit, that they will almost certainly not be able to compete with "free" - although monthly unlimited subscriptions come close.

The rest are problems of their own making. I described how I downloaded The Phantom Menace back in 1999. 13 long years later and the movie industry still isn't even close to where it needs to be.

Amazon have done pretty well from selling raw MP3s - a simple web interface, pay a small bit of money, instant high-quality download which is DRM free. Where's the equivalent for films? Or for TV? Or radio?

The pernicious restrictions around geography also must end. I want to watch Veep just as much as the Americans do. Why do I have to wait even an hour, let alone a week?

Finally, Star Wars still isn't available to (legally) download. If I have a hankering for Jar Jar Binks at 3AM, I have to order a DVD and wait while it is physically transported from a warehouse. That's such a 19th Century way of thinking that it hurts my brain.

Get all that right and maybe - just maybe - the "piracy problem" will solve itself.

Of course, alternatively, it may be too late. For 13 years people have been used to downloading without paying. That's a long period of learned behaviour. How content providers can convince people to change the habit of a lifetime is beyond my knowledge.