Going Public: How we can get off Facebook and control our own data

With over 2.7 billion monthly active users, Facebook is the most popular social network worldwide. From local reading groups to concert venues to national museums, many organizations rely on the platform to share their events and generate an audience. But this reliance on Facebook to increase followers and reach an audience also makes us complicit in the extraction of user data and the manipulation of user behaviour that Facebook profits so much from. So what are our alternatives? Can we create our own network of calendars to stay up to date on, and share our own, events? What would those calendars even look like? Luckily, Joel Galvez—maker of wireframes, working prototypes, and websites—reached out to us last summer to test the pilot of his open calendar project. To get a better understanding of public data and how we can migrate away from Facebook as our main events calendar, I spoke to Joel about his latest project apocalendar.today.

Margarita Osipian: We often hear from our friends or colleagues that they would love to get off Facebook, but that it serves as such a good event calendar for them or for the events that they organise. This is especially true in the art and culture world. Was this the reason you wanted to start this open calendar? 

Joel Galvez: Yes. It started a bit more selfish perhaps. Me, having quit Facebook, trying to alleviate my own FOMO and then figuring maybe I’m not alone with this wish. I also assumed that being dependent on Facebook for advertising events must be frustrating for organizations. This is a bit of a separate issue than using Facebook as a social network. From the reactions I’m getting it seems that I’m right in my assumption.

MO: To begin, can you tell me a bit about apocalendar.today and how it works?

JG: This project is actually three separate but interconnected projects/initiatives: getting places or organizations to make their calendar data public and part of a public “pool” of data; associating a domain with a calendar—to make it easy to find; and the apocalendar.today, one basic application using this pool of data.

1. To get places that do public events to open their calendar data and make it public.
This is the biggest part of the project and the most work. If a theatre or gallery has a calendar baked into their website, they can automatically export it. They need to pay their developer 4 hours to do this, but once they take care of this first step things get exported automatically. This is the best long term solution in most cases.
Spaces or organizations can also manually upload their event data to Google Calendar or Nextcloud. Then there is no programming involved but the events need to be added separately, so that means continuous work.

Perhaps this project could help smaller spaces without a website. Say you run a small place with small means, and you have a simple website with some images and links that you update manually. Maybe this project can help, so that you don’t need to create a more complicated website with a calendar as a communication channel. You can use this calendar for that purpose, and keep your website basic.

2. Associate a domain with a calendar.
I should be able find the public calendar of a place by only knowing the domain name. This connection has to be machine-readable, so it’s not enough to just list the calendar on the website. It’s the same idea as the idea of the semantic web from decades ago, that every piece of data should be readable by machines, as well as humans. This is a mini-mini version of that—and only for one specific purpose (events). The semantic web was a ambitious project to make all data machine readable—this is just about calendar data (and more low-tech, perhaps).

I have the very long term and slightly utopian dream that I would manage to create a form of standard for this—how to associate this data (various communication “channels”, such as mail, Twitter and a calendar) with a domain. This impromptu ‘standard’, until now backed by the entirety of 1 person (me), is a text file called “channels-manifest.json”. The idea is that if you go to joelgalvez.com, by only knowing my domain name it should be possible to find out all my communication “channels”—such as my twitter account, instagram, my e-mail, and then also my public calendar. This data should be discoverable by computers, not humans, so it can be used in applications (like apocalendar.today). If this information was only visible on my website (to human eyes), I would have to “scrape” everyone’s websites to try and extract it—essentially building a new search engine. It would be a bit of a hassle.

I’m quite surprised there isn’t a standard for this already. (If there is, let me know!). This is an example for The Hmm: https://thehmm.nl/channels-manifest.json. In this file you advertise your public calendar, so any computer can can find it, and it’s machine-readable. How this file looks like is a bit more expanded here: publicdata.events

3. Then there’s apocalendar.today—my particular calendar.
I built this calendar just to show the most basic thing you can do with this calendar data. Currently the website looks really boring. There are about 15 online calendars now with Amsterdam art spaces. I need another 10-20 or so for it to be a decent source for staying updated about this kind of stuff in Amsterdam. A handful of them are crucial for this to work. It’s hard work to get them on board, but not impossible.

I don’t know how to organize thousands of calendars—if it ever gets there. By starting with my particular calendar, it’s possible to postpone that issue and experiment with the organization collectively, later on. If this can work for the local art scene, maybe it can work for other situations later on. But I think it has to work here first, to have grounding and legitimacy. I’m not sure yet if it will get there, but I lobby the best I can 🙂

So, project 1 & 2 together is publicdata.events. 3 is apocalendar.today, and they are separate. publicdata.events is the real project and apocalendar.today is just an example application on top.

MO: In the short introduction video you made about the project, you show that the calendar functions by having open and distributed data. What is the importance for you to have this distributed calendar system? And how does this connect to concepts like “domain-based trust”.

JG: Domain names have been around since the beginning. We’re used to them in relation to ‘websites’. I think they might have something to offer as a way to visualize varying modes of trust and might help as a tool for categorization, etc. In mastodon (an open/distributed Twitter clone) you have “mastodon.social” that has one set of values and “queer.hacktivis.me” that has some other values. If your handle ends with “queer.hacktivis.me”, that reflects on your public image. In a similar way, if your calendar is in my list, you adhere to my values symbolized by the domain “apocalendar.today”.

From a user perspective the domain has become synonymous with a data-silo, the platform. Data from domains don’t mix, at least from a user perspective (even if a lot happens behind the scenes).

If we do a thought experiment and assumed that both The Guardian and 4chan used some standard, or protocol, on how to show comments (say, the old standard from the semantic web), I could then mix the comments from these two data sources into one discussion forum in a third place.

I trust data from 4chan in one way and data from The Guardian in another way.

Now, the design problem of how to treat this difference in trust is a separate concern from 4chan or The Guardian themselves. Maybe the 4chan comments are in a lighter shade of gray, or with a warning triangle 🙂 This is my decision. I don’t have to pressure 4chan into employing ‘fact checkers’, since the fact checking is done elsewhere. This is the promise of open data and the old promise of the semantic web, as I mentioned earlier.

4chan would then become a form of data source that you trust in a certain way, rather than a “website” or a closed “platform”.

So then the question becomes, why didn’t the semantic web take off more? There are many reasons. One reason is that it doesn’t benefit the person doing the work directly. It goes against the profit interest of the platform and their data hoarding.

Anyway, if I go back to my calendar project, the pressing issue now is rights, I think. What if someone uses my data in a way that I don’t like—what can I do about that, if it happens? I have to look into that. If you read this and you’re good at EU data law, let me know! In terms of rights, it’s also important to understand that there are different kinds of ‘public’. This is both a legal issue and an emotional issue. Facebook provides this sense of control over who sees your data. Even if you post something “public for everyone” on Facebook that data is not machine-readable. It can (on the surface, at least) only be spread by humans, so there is still a limit to how it spreads. This creates a sense of protection and control. Cambridge Analytica has, amongst other things, proven that you can’t really trust this mechanism, but still – going 100% public is scary, because it means giving up this sense of control, even if it’s not entirely true. It’s an emotional difference.

Facebook would obviously never make their data machine readable, because then someone can fork it and make Facebook 2.

Data on a regular website is also only 99% public, it has to be scraped to be useful as data. Nobody does that, except Google and some spammers, so it’s not 100% public, like the data on publicdata.events. The data there is “pure”—ready for machine consumption. It can be mass harvested for whatever purposes with a couple of lines of code. I’m inviting people to do it.

Anyway, if we manage to keep the data public it means no security, no logins, passwords, nothing to hack—It makes everything so much simpler. I think and hope there is a core of data that can be entirely public, so I don’t have to resort to locking things down behind passwords and permissions. I’m hoping public events can be that type of data.

In a way publicdata.events relies on the question whether anything remains from the internet of 20 years ago when everything was equally available to anyone. I’m not sentimental, I just want to keep it simple, low-tech and unhackable.

Can 100% public exist today? I hope so.

Anyway, for the organizations that invest in this, the distribution is important. For them to know that it doesn’t stand and fall with me (as long as there is a critical mass). I cannot suddenly wake up one day and try to be Jeff Bezos. If I try to monetize this in a bad way, someone will ‘fork’ my calendar. I don’t control the data – it’s not on my servers. Forking means making a copy/change that you take responsibility for and publish under a different domain. So if you create a variant of my calendar, like, “apocalendar.tomorrow”, your audience will inscribe a different kind of trust depending on why you chose to make that fork. You can copy and change, but you have to build your own trust for your own audience.

In the end, all there is, is various levels of trust in various domain names. I think we’re so used to platforms we have forgotten to think in terms of domains and varying levels of trust!

MO: In the past there have been attempts to make new social networking platforms (like Ello) as a response to Facebook, but often there is not enough critical mass to make a full transition. Do you want to (or need to) reach a lot of organizations or institutions for this to work well? 

JG: I have an Ello account somewhere! 😀 The network effect is this big monster that kills everything that isn’t #1. However, this is not a network, this is really only about staying up to date from various sources, If I can make it work for myself maybe it can work for others 🙂

As a start, I’m proposing a networky structure on top to keep track of some calendars—but this can change. This current structure is a simple form of federation. Brussels.fyi (run by Byrthe Lemmens) has a focus on Brussels. They trust me, so brussels.fyi subscribes to updates from apocalendar.today, and vice versa. By trusting them you indirectly trust me—a simple network of trust. It’s a simple model to start with. You can also track the chain of trust: on brussels.fyi you can see that almost all calendars come from apocalendar.today.

The hope is that, if you live in Brussels, you can check brussels.fyi to stay updated. But if you travel from Amsterdam to Brussels you can still use apocalendar.today. You only have to click the “Brussels” tag and you’ll get the same information. This is because I trust brussels.fyi to automatically give me all new calendars. Me and Byrthe form a tiny network of trust. It’s a very low tech way to get started.

Maybe, in the end, it’s easier to have a huge database distributed as a torrent or versioned via .dat/IPFS, or something 😀 It would make it easier to fork a list of calendars that way perhaps. We’ll see, once/if things get to that scale. The important part is that it can change, when needed. Maybe there will be a blockchain involved one day, haha 😀

Back to earth: There are 20-30 art spaces in Amsterdam that I’m interested in. If it works for them I have achieved my own goal to stay up to date here. If it works for them (and me) it can maybe work in other places and situations.

Compared to Ello, this is more top-down. I need to convince a bunch of organizations, not individuals. As for usage, if it works, is reliable and practical, eventually it will be used. Maybe it’s a bit naive, but some naivety is needed to work on a thing like this. Organizations will soon be able to link to their own calendars, this is a way it can slowly be advertised.

MO: A lot of your other work focuses on making wireframes and building websites. What structures, features, and functionalities did you take into account when building the open calendar site? 

JG: Not much 🙂 I’m using a very standard calendar interface (the FullCalendar library). It’s super boring. I have to make a nicer interface next! Or better yet, I might have someone interested in trying to make an alternative (nicer) interface—that would be so super cool!

MO: What are your future plans for the open calendar? How do you hope that people use it and help develop it further? 

JG: My dream is that there is enough public data around that I, and others, can stay up to date without relying on specific websites or platforms. And also that others can use this data in new ways.