Blog Title

Fediverse vs. Bluesky

2023-05-06T00:00:00Z

Nobody:

Me: Let me tell you all about my thoughts on the recent rivalry (read: fairly one-sided grumbling on the Fedi side) between Bluesky and the Fediverse.

What I think of the “conflict”: Wholly misguided. But I’m glad it’s happening, because it’s galvanized a bunch of people and projects on the Fediverse side.

I have no doubt that a bridge between Bluesky and Fediverse will go up in very short order (already being worked on at @activitypubblueskybridge@venera.social). Some instances will block it, most others won’t, and people will continue posting and interacting as usual.

What I think of Bluesky: As always, I look at who’s doing the project first, and at the code and architecture a distant second. And the Bluesky team (Jay, Paul, Emily, David, Why, many others) are some top-notch humans — I’ve met and talked to many of them in person and online. I think I understand, overall, their motives and what they’re trying to achieve, and I want them to succeed (just as I do with the Fediverse).

What I think of the Bluesky data model: Siiiigh, ok, so, do I wish they at least started with the ActivityStreams2 data model for posts and tried to extend from there? Yes. Do I understand why they studied it and decided to not use it? After a bunch of discussion, yes :/ Regardless, I think we (the builders of the protocol bridges, and the larger Social Web) will be able to translate between the two data models fairly easily.

What I think of the AT Protocol: Do I wish the team didn’t re-invent JSON-RPC and JSON Schemas? Yeah, my heart always leans towards interop- and existing spec-first. Do I understand why they did it? Yeah, maybe, grudgingly. Change is bad, but also, they wanted to play around with some new options and technologies, and I highly suspect it will help improve the Social Web overall.

What I think of the Bluesky architecture: Ok, so, this is where I’m kind of boggled by the current Fediverse discourse. That architecture? Is almost exactly what the Fediverse will end up with, as it scales. Third-party search indexing (opt-in, of course) is a general tool of a decentralized Web, there’s nothing AT-specific about it. Same with all the other pieces.

What I think of the source of Bluesky funding: Heeeere’s the thing. If a billionaire wanted to give me a million $ or ten, and I saw it as an opportunity to further the cause of the Open Social Web, would I do the same thing Bluesky is doing? Yes, IN A HEARTBEAT. (So, if you know any extra $ burning people’s pockets, hook me up.) Except I think I’d re-use existing tech more.

Just whose team am I on? Uh… I’m on team Plurality, Queer Post-Scarcity Space Anarchism, and Libre and Liberatory Software. I’m against fascism, and for trying to survive the current Multicrisis/Jackpot with the least loss of human lives and least species extinctions. (Except for deer ticks, those can seriously go to hell.) So in that regard, I think (until proof to the contrary) that the Bluesky team is on our side.

But so, where am I going to be spending my time and effort? On the Fediverse side, of course.

Btw, I’m not really thrilled with the term “Fediverse”. It’s better than “Mastodon”, of course, for obvious reasons. And better than “ActivityPub” (since that’s just ONE protocol of the whole stack). But the thing is.. there’s nothing sacred about federation. It’s just one (albeit important) tool in the distributed system toolbox. To name our whole scene after it, is like naming us “Array-ists”, or “Linked List-ists”. It’s just a low level detail. Let’s just call us for what we are: the Open Social Web.

Anyways, what do I think of the current Fediverse: Well, it’s my people. I love it and use it, and am hoping to help it in whatever ways possible (paying instance admins, reviving the W3C Social Web Incubation Community Group for standards work, building bridges). Do I think it needs some improvements? Oh, hells yes — and I’m’a tell you all about those, shortly.

So, we have a lot of work to do. And remember, we’re aiming for the Pluriverse. And lots of bridges.

Understanding Linked Data

2018-07-31T00:00:00Z

What does the concept of Linked Data mean to you as a developer? It means that you have datasets that have the following properties:

Globally unique IDs (since they use URIs for IDs). Also, you can almost always dereference those IDs and get more detailed useful data from them. Globally unique, collision free, reusable property names (or column names, if you’re coming from an RDBMS world). The datasets are self-documenting and self-describing. If you dereference each of the unique property names, you get comments, context, data types, and if you’re lucky, validatable schemas.

Linked Data from First Principles

The easiest way to understand the benefits and challenges of Linked Data is to start with something familiar to most developers — data in the CSV format. Let’s say we want to store some user records:

id	name	birth_date
1	Alice	1990-01-01
2	Bob	1990-02-02
3	Cindy	1990-03-03

We have data, we have property names on the first line, but there are several challenges here. For one, although the meanings of the example property names are fairly easy to guess, anybody who’s worked with CSV datasets knows that this is not always the case. It would be of immense help to be able to have some sort of explanations or comments alongside that first line, to understand what the properties are and how to process them. Along the same lines, the schema of the properties is far from clear (such as their data types and validation logic). Lastly, this dataset is not very portable, in terms of its IDs. They appear to be the usual sort of auto-incrementing integer, but it’s not easy to add them to an existing dataset (say, a Users table), since those IDs could already be taken up by existing users. To put it another way, those IDs are not very collision-resistant.

Let’s put that same dataset into JSON format, to make it slightly easier for developers to understand (and use in their code).

[
  { "id": 1, "name": "Alice", "birth_date": "1990-01-01" },
  { "id": 2, "name": "Bob", "birth_date": "1995-02-02" },
  { "id": 3, "name": "Cindy", "birth_date": "1999-01-01" }
]

A little better — we can now refer to a property from a parsed row by name (say, user.name) instead of by index (user[1]).

Now, imagine if we could give each of those users a globally unique id. Maybe each of them has their own domain name. Or failing that, an account on some service provider. Then we would have:

[
  { "id": "http://www.alice.com#me", "name": "Alice", "birth_date": "1990-01-01" },
  { "id": "http://bob.provider.com#about", "name": "Bob", "birth_date": "1995-02-02" },
  { "id": "http://cindy.provider.com#about", "name": "Cindy", "birth_date": "1999-01-01" }
]

Now the dataset becomes much more portable. We can merge it into existing datasets with no fear of id collisions. Not only that, but now we can dereference those IDs and hopefully be able to get more useful data, such as a public user profile.

Incidentally, HTTP URIs is not the only way to have globally unique identifiers. Other schemes have been used, such as XRI. The benefit of HTTP URIs should be obvious, however — the tooling and infrastructure and developer familiarity with those is considerable.

The property names are still a bit ambiguous though. Does name mean full name, or just the given name? To address this, we could do the same thing with property names as we did with the IDs, and just use URIs:

[
  {
    "id": "http://www.alice.com#me",
    "http://schema.org/givenName": "Alice",
    "http://schema.org/birthDate": "1990-01-01"
  },
  {
    "id": "http://bob.provider.com#about",
    "http://schema.org/givenName": "Bob",
    "http://schema.org/birthDate": "1995-02-02"
  },
  {
    "id": "http://cindy.provider.com#about",
    "http://schema.org/givenName": "Cindy",
    "http://schema.org/birthDate": "1999-01-01"
  }
]

Now, all of a sudden, we have reusable, unambiguous properties. With the added benefit of — we can resolve those properties as HTTP URIs and get a human-readable comment explaining its semantics, and the data format and validation constraints for the values (for example, the fact that the birthDate is in ISO 8601 date format). And they're reusable in the sense of, now app developers are encouraged to simply use http://schema.org/birthDate for the birth date property name, instead of various incompatible combinations of birthdate, birth_date, bd, and so on.

Of course, repeating the full URL for the property name for each record gets a little verbose, and not very DRY. Let’s factor out the property name URIs, and put them in a lookup dictionary, in their own context section.

{
  "context": {
    "givenName": "http://schema.org/givenName",
    "birthDate": "http://schema.org/birthDate"
  },
  "data": [
    {
      "id": "http://www.alice.com#me",
      "givenName": "Alice",
      "birthDate": "1990-01-01"
    },
    {
      "id": "http://bob.provider.com#about",
      "givenName": "Bob",
      "birthDate": "1995-02-02"
    },
    {
      "id": "http://cindy.provider.com#about",
      "givenName": "Cindy",
      "birthDate": "1999-01-01"
    }
  ]
}

And now we have the best of both worlds. We have compact property names (so that we can once again refer to a parsed user’s property as user.givenName instead of something horrible like user['http://schema.org/givenName']). And we still retain the benefit of globally unique unambiguous dereferenceable property names (they just get short, readable local aliases). (By the way, a thematic grouping of properties, such as http://schema.org/, is referred to as a vocabulary or ontology in the Linked Data community.)

Congratulations, we have just created a proper Linked Data document. And with a few tweaks (we’ll use the reserved properties @id and @context, and @graph instead of data), we can turn this into full-fledged RDF based linked data, using the JSON-LD serialization format. (You can have Linked Data without using any of the RDF formats, it's just that by using them, you get access to a rich ecosystem of tools, standards, databases, validators, reasoners and deduction engines, a standardized query syntax, and so on.)

{
  "@context": {
    "givenName": "http://schema.org/givenName",
    "birthDate": "http://schema.org/birthDate"
  },
  "@graph": [
    {
      "@id": "http://www.alice.com#me",
      "givenName": "Alice",
      "birthDate": "1990-01-01"
    },
    {
      "@id": "http://bob.provider.com#about",
      "givenName": "Bob",
      "birthDate": "1995-02-02"
    },
    {
      "@id": "http://cindy.provider.com#about",
      "givenName": "Cindy",
      "birthDate": "1999-01-01"
    }
  ]
}

Linked Data Benefits

So what did all of that get us? The benefits of the Linked Data approach are several.

Easier data merging and schema migration. Mashups (combining data from heterogenous sources) become much easier, due to unique IDs and unambiguous properties. The flat graph based structure of most linked data formats (composite structures are expressed via local links, instead of nested documents) also makes merging datasets and schema migration much easier.

Data is discoverable (from IDs), self-describing and self-documenting.

Reuse and interop. Unique property names (that are published on the net, well described and schema-specified) encourage interop and reuse, and help cut down on constant wheel reinventing.

Better searches. If you embed linked data in your web pages (in JSON-LD format, or embedded in HTML attributes using the RDFa format), Google will actually parse it and use it to enhance search results. See Google’s Introduction to Structured Data for further discussion.

Rich toolset/ecosystem. By using an RDF based format, you get a lot of extra tooling and infrastructure for free (in addition to the existing JSON-based toolsets, for example).

Linked Data Challenges

In going from something like CSV to RDF-based linked data, you’ve probably picked up on a few implications and challenges to organizing your data in this fashion. Let’s go over a few of those.

URIs. Giving URIs to things is not always easy.

Schema discovery. Discovering, choosing or creating schemas (vocabularies) that fit your use case is sometimes challenging. But at least with linked data, you have the option to browse and study listings/directories of such schemas (unlike with database table schemas, for example). Schema.org/schemas is a good place to start.

Availability. Linking to things on the net means you are depending on the uptime of other systems. (See also Leslie Lamport’s quote, “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable”.) Fortunately, actually dereferencing the links of properties or IDs is not mission critical, but is more helpful during development and design phases. To put it another way, you can still use http://www.alice.com/#about as a good user ID even if Alice's website happens to be down during a given day -- browsing linked data is an additional benefit and possibility, instead of a core operation.

Data Longevity and Data-Centric Software

2016-11-17T00:00:00Z

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Zawinski's Law of Software Envelopment

I wonder if there's a similar law having to do with APIs, or backup/export functionality, or open standards. If there is not, there should be. Something like "Law of Software Superiority".

Rules of Software Superiority

It comes down to this. If you have a choice of which software (or web app or service) to use:

Choose the one with an API over the one that doesn't
If choosing between two APIs, pick one that uses standard protocols and data formats, or is an open standard itself
Choose one that has an Export/backup functionality
Choose one that stores its data in a standard (spec'd out or well understood) format
Choose one that is open-source over one that isn't. Hell, go wild, and choose free software (in the Stallman sense) over merely open source (and of course over proprietary)
That said, if the choice is between free software that uses an obscure/undocumented data format (that is, it's not clear how you'd get your data out) and proprietary software that has a clear backup/export strategy to an understandable format... choose the proprietary one. The safety and longevity of your data is of paramount importance.

These preferences (libre > open-source > proprietary, api > backup/export > neither, open data format > proprietary/undocumented format) are not about idealism (unless that's your thing, in which case, by all means). They are about reducing risk. Chances are incredibly high that:

If you're using an online service or a commercial app, the company will go out of business, or even more likely, will get acquired or merge with another (which will not care about product continuity).
If the company doesn't change hands, the project (or app or service) will get discontinued, or pivot to a direction you don't like.
Your account can be locked out or revoked at any time, due to over-zealous content filtering, accounting errors, etc.
Even for open-source projects, the project leadership may abandon it and move on, or again, take it in a direction that makes it unusable to you.

This is not meant to discourage you, or sound overly pessimistic. This is just a simple reality of living with software. My point is that if you consistently choose software and services that make it possible to get your data out, you can be at peace with all these eventualities.

Ok, so, the API thing... The important thing here is to be able to get the data out of the software. (And, only secondarily useful for actually scripting / extending it / mashups.) If you can get to the data (because it lives on your computer's hard drive) but can't use it (it's in an undocumented/proprietary format), it's no good. Similarly, if it's in a simple or well-understood format (say, blog posts, or pictures or whatever) but you can't get to it (ahem, I'm looking at you, various social media sites), again, useless. At best, you will have to resort to the nightmare of screen-scraping.

Data-Centric Software

There is a type of software that, by its very nature, lends itself well to preserving the longevity of your data, and compares favorably in terms of the above rules. And that is data-centric software, where the user has control over data in a well-understood and documented format, and thus has a choice of which apps to use to work with it. Chances are you're very familiar with this sort of model, just from using popular desktop applications. Examples include text editing and word processing, spreadsheets, presentations, image editing. Personal accounting software (Quickbooks and the like) is actually almost there, although there are occasional subtle incompatibilities with formats.

The situation gets a lot more difficult (in terms of users being able to control their data, and be able to have a choice of interchangeable/competing applications) once you get into online services and applications, and mobile apps. In the world of traditional desktop software, data lives on generic storage (hard drives, etc), and most applications have equal access to it. In the mobile app world, aside from a small handful of standardized shared resources (basically, your camera roll), storage mechanisms are a lot more opaque, and each app is encouraged to use its own individual slices of storage.

And with online services and social media apps, the situation is even worse. Unless a service is progressive enough to expose a comprehensive API, your data is pretty much locked in there, and good luck using third-party services with it.

It doesn't have to be this way, though. There is nothing about web apps or mobile apps that inherently forbids them from being data-centric, or makes interoperability impossible. These days, browser applications can actually have access to your hard drive (if you let them), and cheap cloud service providers can serve the role of generic data stores (just like your computer's hard drive). Your data (whether it's documents or images or even social media type things like blog posts and status updates) could be under your control, and you could have the choice of interoperable competing software with which to edit it.

This goal of enabling interoperable data-centric web applications that use generic storage (local or cloud-based) is one of our main motivations at the Solid project (project repo | specs). (There are other goals, like making decentralized app development easier, encouraging the use of linked data, breaking the deadlock of various social media monopolies, and so on.) It's an ambitious project, and involves a lot of interesting engineering and research challenges (as does all large-scale decentralized software). I'll get into some of the technical challenges (and our solutions) in subsequent posts.

Standards and Protocols are Holy

2014-06-20T00:00:00Z

In biology, the individual organism is ephemeral. Each individual is incredibly fragile, and has a built-in limited lifespans, not to mention a good chance of meeting with accidental death at any moment.

The only things that matter, that have at least a shot at longevity, are genes (and species, really).

With humans, again, the individual, while certainly extremely important, is very fragile and limited in lifespan (just ask Tolkien's Ringwraiths, "Nine for Mortal Men, doomed to die" and all that). Genes certainly matter (the importance of family). But in addition, memes (in the Dawkins sense, as ideas and units of cultural propagation) become incredibly important, and offer another venue for longevity.

To put it another way, the effect of an individual on the world is threefold: their actions during their lifetime, their propagated genes (arguably the least important), and their cultural legacy (their propagated memes, the ideas and memories they leave behind). If "cultural legacy" sounds too grand or abstract, remember that it operates on the tiniest of scales. If you have a child, how you raise it and the things that you teach it (this becomes a part of your cultural legacy, the memes that you propagate) is much more important than the genes it inherits. On a smaller scale, that book you lent to your friend's kid? You know the one, that sparked off their lifelong love of scifi and fantasy, or of problem solving, or poetry, or riding horses, or whatever? That's a part of your cultural legacy. Obviously, if you wrote that book, your legacy is even greater. But in the world of memes and ideas, curation, rebroadcasting, analysis and commentary, are almost as important as actual idea creation.

Sidenote: if one wanted to rank those three factors (actions, genes, memes) in the order of importance (a questionably useful endeavour), I would argue that an individual's cultural legacy, the ideas and memes, are of the highest import, and leave the largest influence. Certainly more important than genes (unless you're Magneto, and your kids can somehow inherit a never-before-seen genetic mutation that can save the world). And more important than individual actions. Think of history's high-impact individuals, like Margaret Thatcher, Alexander the Great, Martin Luther King or Eleanor of Acquitaine. These were no slouches, when it came to individual actions and their effect on the world. But consider how much greater the impact of their cultural legacy is. Of the ideas, laws and concepts that came into the world as a result of their actions.

Now consider the world of technology, specifically software.

As engineers and developers, we spend so much of our time involved in specific tech stacks. Endlessly debating the merits of a particular tool, programming language, framework, infrastucture components or applications.

Here's my point: individual systems, applications, and frameworks don't matter that much. But formats, standards and protocols are holy (whether de-facto or de-jure). (Similarly, the ability to export and import, is the single most important feature that your software can have). This is related to the concept of living software, though different in emphasis.

In terms of impact and longevity, the importance of standards and protocols over individual applications is the equivalent to the importance of genes and species over individual organisms, or to the importance of cultural legacy and memes over a person's genes or individual actions.

MySQL and Postgres? Yes, they're important, sort of. But only because of the ANSI SQL standard. (And because of the CSV format for importing/exporting data between them).

The Mosaic browser, Netscape, IE, Firefox or Chrome? Again, also important. But only insofar as they implement the HTTP protocol and the HTML/CSS/ECMAscript formats. (And especially important in the battle for those protocols and formats, using the usual weapons of embrace-and-extend, nonstandard features and so on).

Pay attention to these. Formats, standards and protocols are an important battleground, one that does not receive enough attention in our open source culture. Identify and stake out the crucial ones, and protect them. Get involved in their formation and implementation (again, you can have an enormous influence by just writing a useful library such as Markdown, even if you don't have a seat on a W3C standards workgroup).

Thoughts on a Mars Colony

2014-06-03T00:00:00Z

(Note: I wrote this as an answer for a Quora question originally.)

How many people are required for a self-sustaining Mars colony?

What level of technology would be required to survive several generations?

These are two separate questions.

How many people are required for a self-sustaining population anywhere (genetically speaking)?

The answer seems to be: about the size of a small village. (Incidentally, these are historically proven to support stable populations almost indefinitely).

This article, for example: "Magic number" for space pioneers calculated gives the number at about 160.

With some luck, realllly good medical care, and careful genetic screening (to watch out for harmful recessive genes, etc), you could probably bump that down to about 100. But you know how it is, the more, the better.

What level of technology would be required to survive several generations on Mars?

(To be specific, this includes "What level of technology is required to GET (a bunch of people) to Mars" and "What level of technology is required to sustainably live on Mars? (versus, the Moon, for example - it's very slightly different").

First of all, this is a popular question to ask. We all want to know this!

See for example:

But, let's take a stab at outlining what's involved.

Getting to Mars

What we need, to get a village full of people to Mars:

#1 (by a big margin) Better Propulsion!

Here's the thing you need to understand about space colonization. It's all about how much mass you can haul across long distances (and how fast). Everything else is secondary. If you can bring a lot of mass with you, you can colonize with very primitive technology. If you can't, that's when high tech becomes the limiting factor - that's when you need all sorts of research and invention, on how to make everything super small and efficient, and to learn how to make everything when you get there.

This is the biggest challenge we have. Our current engines (Apollo style chemical rockets) are just not enough.

Analogy Alert: Think of a modern highrise hotel. Now imagine that you have to pick up and move the hotel (all of its people and equipment) to a nearby city (let's say from New York to Boston), and all you had for transportation was a shopping cart.

(Even if it's a big shopping cart, like from Home Depot).

Can you do it? Sure. It's theoretically possible.

But if all you have is a shopping cart, it's going to take a long time (think of all of the trips you have to take!) and is going to be insanely difficult.

And even aside from time and effort, you're going to have to invent and manufacture a lot of custom equipment.

For example, that giant industrial stove in the hotel kitchen, or the massive washing machines in the basement? How are you going to fit that onto your shopping cart? You aren't. You'll need to pay an industrial engineering company to design and make a big stove/washing machine/whatever that can be disassembled into small pieces which fit into the cart (plus careful instruction manuals on how to do it) and reassembled at the destination. The cost adds up.

How about that swimming pool? (You'll probably have to take all of the water with you to the new hotel!) That's going to take a LOT of gallon jugs, to move all that.

And that's assuming that you have a building waiting for you in that other city.

With space colonization, it's even worse -- not only do you have to transport the people and the equipment, you'll also be needing to transport all of the building materials to build a new highrise hotel on the other side. (Again, good design can help - see Meet the Man Who Built a 30-Story Building in 15 Days for example - but only up to a point).

So that's the problem. What we have, at best, is a shopping cart. What we need, for this project to be anything more than a pipe dream, is at least a modest fleet of big U-Haul trucks.

Our best hopes, in terms of propulsion (getting to Mars will require a combination of these, most likely) are:

A) Better chemical rockets. We're slowwwly working on these. See for example: NASA | Exploration Systems Development page. Even so, chemical rockets, no matter how good, are still going to be closer to the "shopping cart" end of the scale.

B) Nuclear propulsion. Which would be amazing. You can haul a LOT of mass using nuclear-powered engines. The problem is - politics and legislation and international treaties (people get seriously worked up when you start talking about putting nuclear anything into orbit). Oh, one more thing - you really can't use these methods to get from the ground to Earth orbit. You'll still need good chemical orbital launch systems.

Nuclear space propulsion tech includes:

Nuclear pulse propulsion (Project Orion (nuclear propulsion) or derivatives)
Nuclear thermal rockets, such as the NERVA project
Nuclear electric rocket (this is where you hook up a reactor to an electric propulsion engine, see below)

C) (non-nuclear) Electrically powered spacecraft propulsion

Electric rocket engines are great - they're not powerful like chemical rockets, but they can run continuously. (If you had to go a couple dozen miles on a skateboard, which would you rather have - a single initial push (no matter how powerful), or a small two-stroke engine for a motorized skateboard that ran the whole time?). (These also, obviously, work only in deep space, and won't help you with getting things into Earth orbit).

Some examples of this include:

Ion thrusters - currently working (and in-space) craft that use these: Deep Space 1, Hayabusa, Smart 1, Dawn. See also the canceled Project Prometheus.
Variable Specific Impulse Magnetoplasma Rocket (has been in development for a long time, but hasn't flown on a mission yet)

The problem with electric propulsion (aside from the fact that it's very complicated high tech, and much further research is needed) is: What are you going to power it with? Wouldn't it be great to hook it up to a nice nuclear reactor? Even if it's a low-powered Radioisotope thermoelectric generator like what the Galileo (spacecraft) had? But again, for various political and practical reasons, for the moment, Solar Panels is likely the power source you're going to get.

D) Solar Sails

If you're going to be relying on the sun for power anyways (solar panels powering, say, an ion thruster), the thinking goes - why not skip the middle steps and just have the sunlight bounce off of a sail and provide propulsion more directly?

These can be either physical Solar sails (really thin very tough foil / mirrors) like project Sunjammer (spacecraft), or a Magnetic sail (have the sunlight bounce off of a magnetic field. Still very theoretical).

Solar sails have probably the least amount of research and development so far, among the propulsion systems. If we do get them working, they'll be pretty great - free power/propulsion!

Whew! That was a long section. But that's because Propulsion is 90% of what matters to a colonization effort. All right, what else do we need?

#2 Better Life support systems (we're still on the subject of Getting to Mars)

People will need to breathe, stay warm, drink and eat on the way to Mars (and also while living there - #2 applies to the Living on Mars section as well). Oh, we'll also need better space-toilets. (See Astronautical hygiene)

"A crewmember of typical size requires approximately 5 kg (total) of food, water, and oxygen per day" (from that Life Support systems entry on Wikipedia).

That means - we'll need to both bring a lot of supplies, and learn to recycle the ones we have. And hopefully even produce some, along the way.

How are we doing, in this area? Not so good. Our state of the art is fairly primitive, at the moment (see International Space Station ECLSS for a discussion of the current ISS life support systems).

Evaluation of individual systems:

Heat: pretty good, actually. Like a server room on Earth, all the electric systems on a spacecraft output a lot of heat. Needs power (see below).

Air: Passable. (Pack lots of oxygen, or water (to derive oxygen from)). Also pack plenty of CO2 scrubbers.

Water: Problematic. You'll need to bring along a lot of water (to drink, wash, and electrolyze to produce oxygen). And water recycling is difficult.

For example, the ISS currently has a Urine Processor Assembly and a Water Processor Assembly. (And regular water deliveries from Earth - four per year, minimum). The reclaimed water is mostly fed to the oxygen generating machines, though it is available for drinking in emergencies.

Closed Circuit Air/Water Recycling Systems: Forget it. We have never even experimented with closed life support systems in space. Our best state-of-the-art biosphere tech is something like BIOS-3 (which could support 3 people for 180 days) - and that thing was HUGE. Oh, there was also Biosphere 2, which, again, is the size of several football fields, and even so, had very inconclusive results, in terms of closed system life support. Lots of progress needed here.

Food production: Nope. Meaning, we do not have any experience with growing food in space, so a lot of research needs to be done. On the other hand, given a big enough mass allowance (propulsion again), we can figure this part out.

Sanitation: Passable. (Given enough water). Space toilets, sponge baths (Skylab had enclosed showers), air scrubbers to get sweat/odors/bacteria/vomit (see gravity, below) out of the air. No washing dishes, obviously. Oh, and no laundry - disposable clothes only, currently. See Space Station | The Station | Living in Space

By the way - do you see how this part very much depends on how good your Propulsion systems are? If you can get to Mars fast, you need less supplies and you can get away with more primitive systems. If you can haul a lot of supplies with you, your recycling systems don't need to be as advanced (and you can afford the luxury of oxygen- and food-producing plants).

#3 Power Generation You need a lot of electricity, on the way to Mars , for lights, air conditioning, to power life support and computers, and likely the engines, too, for course correction.

Your options are:

Solar Panels (tech exists, though could stand to be better/more efficient). This is what the International Space Station uses. or
Nuclear reactors (Galileo-style RTGs would work, see above) - Deep space probes use these (plus solar panels), currently.

Incidentally, if you solve the problem of Power Generation and have lots of power to spare (such as, say, with a reactor), you get better propulsion for free (hook up the excess juice to an electric thruster, as discussed above).

#4 Radiation Shielding (extremely helpful) Outside of Earth's protective atmosphere and magnetosphere, you're exposed to high levels of radiation. How bad is it? Well, it depends on how fast you get there. Exposure estimates for a 280-day trip to Mars (see How much radiation will the settlers be exposed to? - Health and Ethics - Mars One) are reasonable (high, but within NASA limits for astronauts).

Obviously, the more protection from radiation you have, the better (less chances of dying from rad poisoning, cancer, etc). Unfortunately, radiation is hard to shield against. You basically need either lots of water (which would also help with life support, obviously), or lots of stone. In short, shielding is incredibly heavy. (But would be solved with better propulsion tech.)

#5 Artificial Gravity (extremely helpful) Space is rough on humans. Aside from radiation exposure, it turns out that being weightless for long periods of time is incredibly hard to deal with (see Effect of spaceflight on the human body). For one, you get serious Motion Sickness (even if you're a highly trained astronaut and are full of anti-motion-sickness meds).

More importantly, you start losing muscle mass and bone mass (see Spaceflight osteopenia), at an average rate of 1-2% bone mass loss per month in zero G. Given the typical flight time to Mars, this starts to add up quickly. (Though hey, what do you know, if you can get there faster (see Propulsion above), you don't need to worry about this as much).

To manage all of this, it would be really nice to have artificial gravity on the way to Mars.

Now, until we have a much better grasp of physics and can generate artificial gravity fields or some such convenience, we either need to rely on centrifugal acceleration (spin the ship/habitat around really fast), or on linear acceleration (step on the gas halfway to Mars, and then step on the brakes the other half. Though this requires better propulsion.) See Artificial gravity (methods of generating section).

#6 Careful Thought/Design to Mitigate Psychological Effects

This one's not so bad. Yes, being enclosed in tiny spaces for months and months is hard psychologically. But at least in this area, we have LOTS of research, throughout history. Monks, prisoners, sailors, submarine crew, astronauts, and so on. Obviously lots of room for improvement, but manageable.

Living on Mars

OK! Assuming we got some people to Mars (a hundred or two) and they survived. What is needed for a self-sustaining colony?

Power Generation Your options are: nuclear reactors, and wind turbines. Fortunately, Mars at least has an atmosphere, and occasionally has wind storms. So that's at least something.

But really, you need decent (lightweight, safe) nuclear reactors. You're not going to be burning coal or oil or gas. No hydroelectric dams. And wind, while possible (not really studied), will not be reliable enough to power a whole colony.

Closed System Life Support Given the cost and the distance (not to mention, risk) involved in shipping things from Earth, the colony is not going to be able to rely on regular care packages from home. It'll need to be able to provide its own air, water, food, and waste recycling.

We do not currently have the technology for closed-system life support, so again, a lot of research will need to be done in this area. We will probably be growing a lot of carefully engineered algae in tanks, use ingenious hydroponics, and so on.

Given enough weight allowance, can can probably set up something like Biosphere-2 or -3, eventually. Though again, think of how much soil - carefully engineered biomass - a farm of that size would require. Soil is something we get for free on Earth, and take very much for granted. Whereas it would take a LOT of composting and poop recycling to make enough soil out of the salty and alkaline Martian sand.

Mining (Water, Oxygen, Metals, Minerals) Even if you figure out all of the details of an efficient closed life-support system, you will still need to keep supplying it with raw materials, constantly.

For example - people, plants and machinery need LOTS OF WATER. You can recycle a lot of it, but you will still need more, no matter what. That means - the colonists must figure out how to find and extract water/ice from Mars surface. We know there's some water ice on Martian polar icecaps. We suspect there might be some hidden underground, but all of that needs to be explored/investigated.

If you find enough water, you can make oxygen out of it. (If you can figure out ways of mining oxygen from Martian soil, even better).

Beyond those two necessities, you will need to learn how to mine and extract everything else you need for a self-sustaining Advanced Manufacturing infrastructure (see below). Think of all of the metals and minerals that we mine and fight over on Earth -- we will need to re-learn new methods of mining/extracting, transporting and processing them on Mars.

Radiation Shielding Though not as bad as outer space, living on Mars also incurs a lot of radiation exposure. Fortunately, once you're on a planet, rad shielding is easy: pile lots and lots of sand and stone on top. Meaning: you're going to build your colony underground. While we don't have a good handle on how to build underground cities (or even small habitats) on Mars, I'm sure we can at least figure this part out, assuming we've solved all of the other problems.

Advanced Manufacturing Same deal as with life support. To be truly self-sustaining, a colony would need to have the tools and knowledge to essentially replicate, on a small scale, a high technological civilization. This will mean: a lot of luck, spare parts, resupply trips from earth. But also, mining robots, 3D printers (though we would need to figure out how to make plastics on Mars), CNC machines & lathes, lots of power tools and hardware.

Basically, we'll need a Martian equivalent of the Global Village Construction Set - a set of self-replicating tools needed to make all of the tools, spacesuits, robots, computers, air filters, life support machines, and everything else people would need.

We do not have this technological capability yet, though we are slowwwly getting there.

Communication (with Earth) At least have a good handle on communication satellite technology. Still, that's a hell of a ping / response time - 4 to 24 minutes, one way, depending on how far apart Mars and Earth are at any time.

Research into Long Term Effects of Low Gravity Will humans be able to survive in the weak gravity field on Mars? Without catastrophic bone loss and so on? We don't know.

Maybe, maybe not. If not, we will need to figure out treatment options (gene therapies, etc) to treat and mitigate this.

All right! Lots to do, better get to it.

The Flattening of Design

2014-05-31T00:00:00Z

I'm still not sure how I feel about the "All the things must be flat" design trend. (Well, that's not true, I certainly hate Windows 8's Xbox-like desktop, the way that the Xbox UI was changed to match it, and the iOS 7 UI update.) Also, I did notice, the other day, how LJ's own user interface was certainly, er, flattenized.

But, I thought this article was interesting:

The Flattening of Design

"[...] companies aren't simply following Microsoft's lead in the quest for flat. There are cultural and technological reasons for this new look and feel."

Also, unrelated (well, related in that the article mentioned that the flat design is reminiscent of these):

Gallery of Russian Propaganda Posters