The web wasn't always just five websites sharing screenshots of the other four, it once was a big playground for small personal sites with fun experiments. The promise of Web3 was to bring that back with new tools: decentralization, blockchains, etc. But maybe we can do that simply with text files and git.

So here are the new personal experiments:

VandeSande.design

Jevons paradox states that when a new technology makes something more efficient, we don't use less of it, we use more. A lot of people who are trying AI love to talk about one-shots, a single prompt that outputs a full game or website. This is a myth: not because the current models aren't capable of delivering a great product in one shot, but because they do, you'd never call that a full website anymore, no more than you'd use a default Wordpress installation and call that a day. Precisely because we can do more, we are expected to do more – what is now considered a basic website will have tests, have been rewritten from scratch twice, and have a lot of features that would have taken a full dev team a few years ago.

But this isn't about AI, it's about creativity. These were websites I wanted to build, which existed only in my head and now are out there in the world and I'm proud of.

Hexagonal.earth

I've already written about my maps extensively. I've spent a full year building the crappiest hexagonal map tools but it's now completely rebuilt as something that anyone can play with. I truly hope it finds the other half dozen people in the world who like hexagonal maps. It has lots of neat features, including a download. If for some reason someone out there wants the original old poster, send me an email.

TriangleofEverything.com

The poster version is now an interactive website. It's useful since now I am able to add a lot more items and check the accuracy of every item on them. Check the Tour version because there are some real neat animations there. And again, if for some reason you do want to get the original poster, feel free to get in touch.

Bonus: hyper-spirographs!

‹1 / 7›

One of the issues I found when trying to represent all objects was how to represent elementary particles. I wanted something that would feel like a real object, but also be based on some math that had a relationship with real science. I started playing around with the idea of a spirograph (you know, these toys to make flower patterns) as a way to see in multiple dimensions: a 2d spirograph is a flower, a 3d is an orbit and you can use hue, transparency and animations to visualize up to six dimensions. Then I found out about Hopf Fibration and Fiber Bundles, a math model that is used a lot in theoretical physics so it felt like a perfect fit.

Anyway if you want to visualize something in 6d and learn about Fiber Bundles more, play around with the hyper-spirograph tool.

If you're also a developer and love terminals, you should follow the official site and install the script.

But for everyone else I build this site, to help you give your AI superpowers. Check the demos and paste the prompt!

So what is it?

You've heard about AI solving Erdos Problems every day. How do they do it? They can do it because math has been formalized in code, mostly by Lean (also a Brazilian developer BTW).

Like Lean, Bend is formally verified. Here's an example of it finding proofs in your browser! bend.how/math/

‹1 / 3›

Now imagine you did that for anything in your code. Imagine you are vibe coding a game and want to make sure the agent doesn't break some fundamental rules.

In this example I built a tiny chess board and added a fundamental rule of white cannot mate in one. Then I asked the AI to add a queen and it refused to do so, because doing that would break the fundamentals of the game.

‹1 / 2›

Can you do it with Lean? Sure, but Bend is not only formal verification. It's about parallelization. Every code runs on the GPU. Anything that can be parallelized will be. It's like writing in CUDA.

I asked Bend to generate these fractals for me – it's not always guaranteed, but more often than not it would make my code 2-10x faster, without any extra effort. I just told it "build it with bend and see what happens". And every pixel is verified to be correct.

For parallel tasks it's great. Not always. For Mandelbrot it was a 100x. Mandelbulb 60x. In Lenia it gave me a 6x improvement. Particle Life was a 5x. Basic Game of Life was a tie. Try it yourself, ask your AI to run the benchmarks and see what it thinks!

I am very excited about the project. Right now it's all open source and free to the world. We are building hoping the world appreciates it.

Ask your agent about Bend.

TLDR:

The DAO holds over 50% of the voting power. These tokens were intended to be distributed for wider governance but were never done because of their economic value. This proposal discusses how we can delegate them (instead of distributing).

The problem

Here are three graphs that can summarize the issues this proposal wants to address:

ENS Governance is clearly in a crisis. Currently, one delegate has enough quorum to not only execute any proposal, but also to outvote the next 50 other delegates. The issue didn’t start when these new votes were delegated, but rather total delegated votes has been consistently going down (except for two jumps, when the same tokens were being delegated and then undelegated and delegated once again). Voter turnout has also been consistently going down: while in the first years it was common to get 3M votes in a proposal, more recent proposals have struggled to meet the quorum.

The core issue is that most of the delegated voting power has been delegated at airdrop and then these delegations slowly trickle down as users sell their tokens and new buyers don’t care enough to delegate them. When someone receives an airdrop token, specially for free, they have a thousand reasons to sell them, and almost no incentives to use them for governance. Over the past few years, MetaGov stewards have tried to do address the issue by making redelegation free, by distributing more ENS tokens to new contributors and by paying users to stake and delegate their ENS. While these have had some mild successes, they have clearly not been able to reverse the overall trend.

This proposal intends to take a different approach and simply delegate voting power to specific players and stakeholders who have an interest in a working ENS. The amount being proposed here is 5M ENS, which should be enough to be impactful but not so much it can’t be reversed.

Who are ENS Stakeholders?

The original airdrop was distributed to all accounts who ever held ens domains, proportionally to the amount of time they held them – the ENS community of users, so to speak. But they are not the only players who can help make or break ENS, the ones whose continued collaboration is required for ENS to succeed. The people who have the power to sucessfully fork it. While there are many factors, I’d enumerate them as such:

Users: wallets, profiles, subdomains. The original airdrop was targeted at people who paid for .eth identities. But these are not the only names currently available: ENS has built and encouraged many other ways in which wallets can distribute free names for their users. Subdomains, names associated with a web TLD, etc. We need those as the initial distribution of users.

Integrations: apps, exchanges and websites. If ENS is not meaningfully integrated in the broad community so that an ENS name can be counted on to always resolve correctly, then it has no value. If the wallets band together and decide to simply pick a different naming system, then ENS will fail.

Developers: core programmers who understand how the system works. Besides labs, there are many other greatly talented developers who have made meaningful contributions to ENS core protocol and its associated libraries. If we don’t foster them, then we will be losing talent.

Legacy naming systems: domain registrars, DNS hosts, IP repositories, etc. I would argue that a continuing cooperation with the legacy domain system is the path for ENS to keep evolving and being deeply integrated with the largest web infrastructure. Web3, NFTs, Decentralized Internet, these might all have been temporary interests that the overall public is not paying attention to anymore, and in general crypto is slowly finding it’s product market fit not in radicalism but in pragmatic integrations with traditional systems.

ENS Governance Community: stewards, delegates, etc. We can talk a lot about the failures of governance, but we also have to point that despite all the weaknesses, ENS has had an active and diverse community of delegates and stewards that should still have an active role and voice and now are unable to express meaningful dissent. We want to make sure these are empowered again.

There might be others and I welcome further suggestions.

The “Community Treasury”

In the original airdrop, 50M ens were distributed, 25M to the .eth holders and 25M to contributors. Another 50M remained in the control of the dao and were described as such:

The remaining 50% of $ENS tokens is allocated to the DAO. 10% of this allocation will be available to the DAO at launch, with the remaining unlocking over 4 years. […] The DAO is encouraged to allocate these tokens towards community focused initiatives to help the development and growth of ENS, such as grants, hackathons, meetups and more.

While the working groups have worked in many community focused initiatives including grants, hackathons, meetups etc, not many of the DAO tokens themselves were distributed for this purpose. In fact only a few delegation distributions have happened and they collectively distributed less than 150k – way under the 10 million per year that were vesting every year. And now, it so happens that we are five years later and all the 55 million tokens (this includes a few unclaimed airdrops) are now freely unvested.

There were many reasons stewards were reluctant to distribute those tokens. Despite the DAO having consistently refused to treat them as financial assets, they were in many moments hundreds of millions of dollars unvested each year and it felt unreasonable and irresponsible to simply send those to users. And in the few cases these were indeed sent, many of them were not necessarily used for voting purposes and rather sold as soon as they were unvested. It’s understandable: when faced with the opportunity to secure a large financial opportunity that can help them in their lives, or simply vote in a governance process they don’t directly benefit from, it’s hard to put blame on those who pick the former.

Proposal

1. Start a nomination process where anyone who wants to be delegated power can put their name forward.

   1. There will be some minimal threshold requirements, like being a person or company (not anon) who owns an ENS, and has participated in discussions before

   2. The candidate will identify itself in one of the stakeholder groups. Each group will have their own particular minimal requirements and a metric. For some, they will require to have at least M of N requirements (ex: 1000 ENS tokens OR 2 ENS related POAPs OR a github with proof of contributions, etc). The metric will be specific for each stakeholder group. For wallet developers we could use MAUs, or for Registrars we could use amount of TLDs connected to ENS, for Governance community we could use total historical delegation, etc.

2. Once the nomination process is over, there will be no vote, instead we will pick the 10 candidates that fare well on the chosen metric for their stakeholder group. If there are less than 10, then all are chosen

3. 5 million ENS tokens will be transferred from the DAO into the multidelegate contract.

4. For each group, 1M ENS tokens will be delegated in total, equally distributed to all selected voters on step 2. If there are less than 10 voters, they will get proportionally, more votes.

5. Selected voters will get no financial exposure to ENS, nor will they be able to have access to the capital. It still belongs to the DAO. They are volunteers. If they do not vote for a period of longer than 6 months, their votes will be redistributed to other members of their group

Collectively this new group of delegates will represent over 60% of the DAO vote. Past delegates will see their voting power increase because they will also collectively get more delegations, proportional to their past delegation power. This means that no one person or group can unilaterally pass proposals anymore and vote buying becomes harder. But it also means the current set of delegates (now with more power) will be able to coordinate and prevent any one of the new stakeholders from capturing governance.

Some considerations

The DAO still holds more than 50% of all tokens. By enacting such reforms, it can substantially change the way decision power is distributed in the DAO. If this proposal passes, and specially if similar proposals are passed in the future delegating even more ENS to new delegates, then the DAO could be seen as quietly moving away from Token Weighted voting to a new system, which is more similar to a multicameral system: the power balance shifts from market power into self-enforced power in which delegates can continuously control who gets the new votes. This could lead to a reformed DAO where multiple stakeholders each get to balance the DAOs best interest – or it could lead to a plutarchy in which few delegates continuously vote to gather more power and control.

Some of these concerns can be addressed by limiting the amount of ENS tokens the DAO itself can access every year. Of course, at some point the real governance decision on the DAO happens outside itself: if ENS has no users, no integrations, no developers, and no connections to legacy systems, then it ceases to matter who gets to vote.

We can also limit some of that concern by making these delegations time limited, so they automatically expire in 2 years, etc.

Open questions

• What is the right amount of ENS to delegate? Too few and the proposal has no teeth, too much and it might give too much power to a new set of delegates

• Who are the true stakeholders of ENS? Is this proposal overlooking some groups?

• This isn’t a total reformation of the DAO, but a step that can be repeated in the future. Many more proposals should be put forth to improve how the overall governance works, to align the incentives of those voting to participate and make sure they have the best interests of the DAO

We wanted organizations that would live in the cloud and only follow hard rules. We built a property ledger that could be used by anyone to manage anything. We wanted an open backend for an open internet. We built a way for people to invest directly into anything.

The world wanted penny stocks and ape pictures. They wanted quick money and cassinos that were open 24/7.

The other day I was reading the docs to invest in a promising startup and realized my money was going to a fund, structured like an spv, who owned shares in a cayman corp, who had a deal with a Delaware llc who was three levels away from the actual cap table. It’s standard.

We built a better system in 2016. You could buy directly from founders, own directly in your wallet, liquid.

The world used it for pumping scams. Nobody else ever wanted to touch that.

I pay my taxes. I don't see where they go. I vote. I can't track where the vote is counted. I can't build my own dashboard. We built a better system than that in 2015. I went to Brasilia and touted that we could "build a better democracy with 100 lines of code". That was probably one of the highlights of my carrier.

I would say the ENS DAO was the model of how everything else should work: transparent, hard rules, uncorruptable.

But the problem is that people are hard to govern, even under the best rules. And we ended up reinventing a lot of existing governance structures to fix our own failings.

This was the ethereum website in 2015. I was the one pushing these pixels and writing the texts. No one told me what to do, I don't even remember how I got assigned the task of building it – I just showed up. Tokens, Crowdsales, DAOs, it was all there. It's quite naïve in retrospect.

‹1 / 4›

I wanted to give an upgraded new map for the Impossible Map I've made last year, and so I started working on an expanded version of Holdridge Life Zones mini-map already present on last year's poster. There's a lot I like about this map: for starters the overall arrangement is inspired by Fuller's "World Island" Dymaxion map, but the external shape is more identifiable as 4 simple hexagons. And there's a lot you can tell about the world history by looking at the map:

• The multi-millennia challenge that is to go from Africa to the southern tip of South America or Australia.

• How Eurasia, specially from Europe to China, works as mostly a few lifezones that can exchange crops and technology, while Africa and the Americas are more diverse (important for fans of Jared Diamond)

• How Norway to Vinland (Newfoundland) is basically a straight-line with island hopping (this map isn't great at maintaining straight line correpondence, and distances can be up to 30% different, but area is very accurate)

• That Russia, while it has a large coastline, it's mostly surrounded by cold non-navigable waters

There are some things I don't wanted to improve upon it. For starters, the fact that topography is absent. Mountains as natural barriers have shaped and still shape history to this day, so a map that doesn't scream about Himalayas or the Andes, that doesn't tell you about the Alps that Hannibal had to cross with elephants, is incomplete. A second factor I dislike is how I need to move some smaller hexagons from the African plate so that South America isn't cut. But I do love the fact that you can rearrange the main hexagons and I realized by simply increasing the hex to a circle I could include South America.

In the Impossible Map I had made topography appear as more stark shadows. Here I decided to make them as icons for hills and mountains, so that it doesn't interfere with the color scheme for Lifezones. Printing them in large sheets, and playing with different arrangements made me feel more like it's a perfect board for a game whose rules I haven't yet discovered. Certainly more about connections and commerce than war, so it's more akin to Ticket to Ride than to Risk.

But it also made me realize that, while I originally started with a Rhombic Dodecahedron, I've stretched and combined so many faces that in the end what I have is a Tetrahedron earth! There are many maps based on tetrahedron, like Lee's Conformal or the Autagraph but they're usually dismissed because it's hard to think of a less spherical solid than the tetrahedron. But what most people don't realize is that when projected on a globe, a spherical tetrahedron face is very "rounded" and is in fact, very similar to the hexagons presented above.

Naturally I've asked myself: what would be the best positions that a tetrahedron can fall on the planet without touching any land? So I did what anyone would do, and built a website for finding tetrahedron vertexes. Go and play around with it. Try to figure out the best position or even click "Scan Map" to search every position possible! I won't give a direct answer because the final results are very subjective. For example, the second best result (measured by least edge distance on land) only does it because it crosses Africa and South America in small slices, but it's not what I would consider a great way to divide the planet in 4 ways. I've even added a distance to land slider so you can select what counts as "too close".

So here we have it. Tetrahedrons divides earth in four logical segments, and while we have to include some distortion, each face is similar to what a globe would look like from that perspective, and the faces, because of their great circle shapes, can be faithfully approximated to hexagons – which are of course, the best way to tile a plane. End of story.

Well, it depends.

Game of Life on a Hexagonal Grid.

As I said, my fascination with maps and specially board games, is about how they simulate complex models using simple rules. Another area where this happens in an interesting manner are zero-player games, like Conway's game of life, or their more interesting modern equivalents like Smooth Life or Particle Life. Of particular interest is the Lenia family, which has found some interesting living specimens that emerge and are able to move, consume matter, reproduce and evolve. One issue in these systems, is that they're very computational heavy: you can only render a tiny minuscule portion of their universe, so small that a Petri Dish feels gargantuan.

I've been asking myself: what if you could come up with simple rules for a very small simulation space and then observe how these rules created more emergent behavior. But then, and that's the most interesting part, you could figure out what are the rules that govern that emergent behavior and use that to simulate a larger, but coarser grid around it? And then you could observe and do again with another coarser and larger grid again, and keep repeating this until you're basically simulating a whole planet?

It's like observing particles and figuring out how they interact and become molecules. And then simulating a simplified model of these molecules with only the chemistry rules we learn, instead of having to run a physics simulation for every molecule. And then observing the rules of biology based on the emerging behavior of the chem rules. In this way, instead of having to model forest by simulating every single atom, you would be running lots of coarse simulations in many levels, and allowing the lessons learn from one level to set the rules for the next one.

That's how I started playing around with the concept of Hex Life.

HexLife is a fluid simulation that uses a series of pigments, that, much like Particle Life, has a series of interaction rules. Some pigments attract, others are repel, and how these interact often leads to interesting patterns. I only simulate a small universe in the grid in the center and when pigments move away from that grid, instead of wrapping around or being ignored, they're picked up by another simulation that surrounds it. That simulation also has similar rules for how colors interact, but it's run on a more coarser grid. Right now it's very buggy and barely functional but the goal is to have it expand from the size of a few molecules to a whole planet, all running from a standard desktop computer.

I am using a hex grid. This would be much more straightforward if I didn't, as having different resolutions in the same square grid is a lot easier, but for some reason I'm doing the more complicated way. And what does the planet looks like?

Right now, Im using an infinite grid outwards, but at some point it probably makes sense to set a boundary that wraps around, like a planet does. If I used the tetrahedron based shape before, that would mean I would have four hexagons arranged inside a single hexagon. That looks simple enough but I was wondering if I could do better with a single hex for the world. Turns out I can, and the answer was staring at me the whole time. One of my favorite papers on the subject of hexagonal maps is called "flow snake earth" by Jacob Rus and describes many ways in which a hexagon can be folded into a sphere. One of the first is achieved by a simple folding into two triangles. A similar approach was made by Oscar Sherman Adams back in 1920 which resulted in this interesting gem:

I really felt it could be improved by having an equal area projection so I decided to take on the challenge. I also wanted the poles to be similar to a hexagon so I divided each hemisphere into 12 triangles that would slowly transition from a hex into a triangle. This is the final result.

It definitely creates a lot more unrecognizable shapes that our previous hex projection did not. You could think of this in 3d as two Tetrahedrons glued to one face, or a Tetrahedral bipyramidal earth. It does allows you to tile the plane and has a hexagonal grid subdivision which is useful for my Hex Life concept.

Anyway, this is a summary of things I've been thinking that are map related which I'm sharing with the world.

Before, I’d like to clarify that this is a debate on how different voting methods lead to different result and not a complaint about the result itself. I would have been writing this regardless of the outcome. In fact the choice I voted as my first choice did not win and there is no way of analyzing the data that it would’ve won.

First, probably the best graphical analysis of the vote can be seen on https://dhive.io/proposal/1478/analytics

The vote’s purpose was both to approve the pilot program and to decide its budget. There were three different budgets, let’s call them Big, Medium and Small, and the option of Rejecting the program as a whole, which set the budget at 0.

Looking at the graph above we can see some interesting things: first, the 10 largest votes represented 90% of the final voting power, and this is the main issue the pilot program is trying to address. The second interesting thing is that everyone’s first choice was roughly split equally in 3 ways, with only one major vote outright rejecting it. For those used to First past the post, even with runoff elections, “vote splitting” is a bad thing, but ranked choice vote is designed to solve that.

In the current scenario the only vote to reject the proposal received the least amount of votes, so that ballot’s voting power was then redirected to the Small option, leading it to reaching over 50% of the votes and therefore winning.

Another visualization of the same data is below:

First, second and third choices are here visualized as different shades of blue. We can see the same scenario: the option for a budget of 0 was the least voted, so these votes were then transferred to the Small option (blue arrow), taking it over the 50% line (red dotted line). But interestingly, this was the ONLY moment where a second choice ballot was considered. The second choice values of the voters that voted for all the other options were never considered. This could lead to some strategic voting: voters who want the largest possible budget would do well of changing their voting preference to put Medium as their first choice and Large as second.

In fact if instead of a ranked choice, let’s assume this election was an approval voting. And for simplicity’s sake, let’s also assume that voters “approved” their first and second choices and did not approve their third and fourth.

In this scenario, the small budget would’ve won 51% of the approval, as it happened with the Instant Run Off method. But the Medium Budget would’ve received an 87% approval! A Big budget would’ve received 49% and the rejection is at 12%. This is because in the current Instant Runoff, the secondary options of most ballots are not being taken in consideration, we are only counting the secondary options of candidates who were eliminated in early rounds.

However, if we assume all voters approve their top 3 preferences, then Small and Medium are tied. This would basically be an election on the least rejected option and it would ignore voters preferred outcome.

This means that if the choice was only between 60k and 30k, then the Medium sized budget would’ve won by a large margin. We can graph all those choices, using the exact voting data as follows:

Putting all the options like this, is called a Condorcet Analysis. We can see that a Medium Budget would’ve been preferred by all voters over any other option (although it’s a very close call when compared to a small budget). The Medium option is what is called a Condorcet Winner, meaning it wins over all other options. The NONE option is a Condorcet Loser, as it loses all one to one comparisons.

This analysis also helps us see how the vote can be changed. Before, a voter that wanted a larger budget would do well by switching their vote from Large first and Medium second into a Medium first and Large second. In this Condorcet scenario that wouldn’t matter, as the Medium x Large preference is very strong.

In this scenario however we can see the closest comparisons are Medium vs Small and Small x Large, both that are almost a tie. But unlike the previous example, a voter who’s interested in the smaller budget possible doesn’t have many options rather than changing someone’s else vote from ranking Medium over Small to the opposite.

There are many ways to tally a Condorcet Election but when there is a clear Condorcet winner, then they always result the same. What is in my opinion the most straightforward method is Copeland/Roundrobin, in which you just count up the victories.

The only issue here is when there is no clear Condorcet winner, then a tie could occur. For example, a big voter that preferred Big over Small over Medium could change the metrics so that the last two disputes would result in a tie. This is why we need to have separate tiebreaker metrics. Here are them for this data set:

In the current Data Set, the Medium Budget has 3 victories. It also has an average of 70% support across all comparisons, it has the highest average margin of victory and has the lowest rejection.

Conclusion

This has been a close election. While the proposal itself was widely approved (as seen by the low numbers of the NONE option), the highest budget was unlikely to win. Medium vs Small budget were a close call, and the result could’ve changed depending on the vote method.

But most important of all is the transparency of the election and it is my belief that Round Robin elections provide more of that.

Is it possible to wrap a sphere using ONLY hexagons?

This is the question that started me in this journey and the one we will be exploring. The answer has some surprising implications, from the big to the fun. In the bigger side, for instance, Uber stores almost all of its geographical information on ride and traffic data using hexagons around the earth. It argues that doing it facilitates computing approximate radius and distance information. Starlink also seems to use hexagons for its geographic data. I said “almost all” because these systems always uses some pentagons in order to wrap around the world.

In the less serious side, many games (both digital and board game) also use hexagonal tiles because it facilitates movements, since all neighboring tiles have the same distance and you don’t need to deal with special cases of “diagonals”. Some famous examples include D&D, Settlers of Catan and Civilization (starting on version IV). Civilization is an interesting example because despite being a simulation of the world’s history, its “earth map” is actually a cylinder, with unit movement wrapping around the east-west axis, but unable to go over the poles. This results in a largely exaggerated northern hemisphere, which might be intentional for gameplay.

Is there any alternative in which the map doesn’t use pentagons, nor uses a cylinder to map the earth? Standup mathematician Matt Parker, when criticizing the UK’s symbol of a soccer ball made of hexagons has called the construction “mathematically impossible” and petitioned the English government to change it. Map designer David Swartz has also called such map “impossible” and when attempting to create a hexagonal map based on an icosahedron projection has simply filled in the missing bits with inexistent ocean, not the first time this was done with that type of map.

Well, you know what they say, when a mathematician says something is impossible…

It’s because it is. They have proof.

In this case the “proof” comes from Euler’s rule for polyhedron’s, which state that there is a constant relationship between the number of faces, vertices and edges of any polyhedron resulting in this formula:

$v-e+f=2$

If we assume that all faces will be n-sided polygons and each vertices connects 3 edges (more on that later), we can rewrite the function in this way:

$\frac{n}{3}-\frac{n}{2}+f=2$

Which is then rearranged in this formula:

$f=\frac{12}{6-n}$

This formula will tell you how many faces you will need in order to make a polyhedron with n-polygonal faces. It results in this helpful little table:

This is a demonstration for the special case of 3 faces per vertice, there are longer proofs that will deal with other cases that are beyond the scope of this post. Suffice to say it’s truly impossible to make a real spherical polihedron out of pure hexagons. So am I done? Of course not.

But that’s not the question being asked here: rather I want to know if there are ways to wrap a sphere using hexagons, like an isomorphic network. This lifts a few constrains, allowing hexagons to be stretched, folded or even to connect to other neighbors in two different ways. In 2017, Jacob Rus published a great paper on Bridges showing a process that could be applied to the tetrahedron, octahedron or the tetrakis hexahedron.

Constructing the Gosper World Map

In this paper we are picking the Rhombic Dodecahedron instead. I’ve chosen this shape because it’s more “roundish” than the aforementioned shapes used in Rus’ paper. A rhombic dodecahedron can also tile a space like the hexagon tiles the plane, so it feels more like the 3D equivalent of the hexagon. But most importantly for our purposes it has 12 faces which can be colored in 4 main “groups”. We then project the earth in the Rhombic Dodecahedron (based on Carlos Furuti’s projection). Finally, we unwrap the rhombic dodecahedron in it’s corresponding network. It gets its name from its “Rhombi”-shaped like faces which are almost a golden rhombus (two equilateral triangles) so let’s stretch each rhombus a little bit until they all fit together.

The result is the world tiled in four hexagons. Each hexagon connects to the other 3 hexagonal tiles in exactly two ways. The result is that if you have two sets of each tile you can create a very simple board game in which pieces move in any of the six hexagonal direction and it allows them to traverse the globe even through the poles. In this animation we can see the pawn on our little game starting in Africa and going in a straight direction, crossing over Asia, the Pacific Ocean, then South America near Antarctica and back to Africa.

There are some other interesting arrangements we can find by moving our pawn around. This is one of my favorites:

It reminds me of Buckminster Fuller’s Dymaxion map, which is one of my favorite maps ever designed. Fuller created it in an attempt of showing the world not as separate continents but rather a single continent, surrounded by a single ocean, as a reminder that we are all one people traveling together in this spaceship earth. It’s a beautiful and striking map, but some people might be turned off by its weird spiky border. Using this technique we were able to recreate the same “spaceship earth” view with a more simplified hexagonal border. We can still go one step further: since all hexagons are flat, we can actually cut and rearrange them in any way we want, making making your own map as simple as putting a puzzle back together.

One of the most interesting arrangements we found was this one, in which the Americas, Europe and Africa are in a more classic north-south arrangement, Australia is now “up” and we can still see Antarctica as a whole continent instead of spread out in the bottom. Even New Zealand is there.

Of course, this uses only the original four hexagons. But one neat thing about a hexagonal grid is that it can be subdivided into smaller hexagons to any resolution we desire. The only issue is that hexagons can’t be perfectly subdivided into smaller ones and there will be some weird overlaps between hexagonal children (in Uber’s H3 system cells will change their parents depending on the resolution). This can be avoided by using instead the Gosper Island, a fractal which is the result of an infinite subdivision of hexagons. It has the same six-sided connectivity of the hexagon, but it can be split into seven perfectly self similar copies of itself.

The resulting map

Putting it all together here is the Gosper World map, a map unlike any you’ve ever seen before:

Some things to note about the map. The areas are constant, so the sizes of continents you see more closely resemble what they truly are. If we leave the original grid visible, it becomes even easier to estimate areas by counting. By an interesting coincidence, the big Gosper arrangement highlighted has approximately 2.6 million square kilometers, or 1 million square miles (one of the rare examples you’ll find of me using imperial units). By counting them, it’s obvious that Africa fills about 12 of the big gosper shapes, while Greenland barely fills one: and indeed Africa has 11.7 million square miles (30 M km²) while Greenland has only 2 M km² or 0.8 million square miles (a relationship that is not immediately obvious by, say, looking at google maps).

Unlike other constant area maps, however, continents are easily identifiable, its easy to see how they connect to each other and Antartica can be seen in it’s full shape and not as a distorted band in the bottom. As mentioned previously, you could simulate a transpolar route by simply making simple hexagonal movements. It’s also possible to understand where each part of the map wraps around to by following the arrows.

Distances however do vary a little bit more, but that distortion is roughly constant on the whole map, instead of concentrated on the edges. A good tool to see how that distortion works is by drawing circles of the same size on the globe and seeing what happens on the resulting map. It’s called a Tissot Indicatrix and it here it is for the Gosper map and some other more classical maps.

And so this is it. I hope I have convinced you that this method creates rather interesting maps with very useful properties. And it can even be used to make a soccer ball made only of hexagons!

“Show us where you cheated!”

At this point the presentation ends and we have a few minutes for questions. A hand goes up in the back.

– HOW DARE YOU!

It’s mathematician and standup comedian Matt Parker, who at this point I had no idea was in attendance.

– NOW GO BACK TO YOUR SLIDE AND SHOW YOU WERE YOU CHEATED

This is completely true story.

I wasn’t expecting him so I tried answering as best as I could at the moment. But before I show the “cheat” here, let me explain how in the world was Parker in my short, 10 minute lecture.

Initially, one of the featured Keynote speakers for Bridges 2024 was supposed to be Grant Sanderson from 3Blue1Brown. For personal reasons he wouldn’t be able to attend so Matt Parker was invited instead. Matt, of course, is known among other things for petitioning the UK government to change its signs depicting the “impossible soccer ball”. I had originally intended my work to be applied to maps, but once I heard this news I decided to take a look on what the process would look like with an actual soccer ball, and, inspired by John Paul’s balls, I started to (re)learn how to sew.

The conference started on a Thursday, my talk was Friday and Matt’s talk was Saturday. I had no idea how accessible Matt would be: maybe he would come in the same morning, give his talk and then fly away to another show, surrounded by a large security detail. If I was lucky I could use my prop on the presentation and then use a photo opportunity to give him before he was whisked away by men dressed in black.

Instead I was pleasantly surprised to bump into him on the very first day. He was there the whole conference, quite approachable and friendly with everyone, so I ended up giving him the badly sewn together ball the first day of the conference. And I guess this picked his curiosity enough for him to attend the talk and ask me a question.

So, detour over: where’s the “cheating"?

As mentioned previously, a real polyhedron made solely of hexagons is impossible, so instead I am treating the hexagons as a polymorphic network, meaning that the most important bit is that every point on the network is able to move in six different directions. Remember how I mentioned that the planet is transformed into 4 hexagonal tiles that can connect to each of the other 3 in different ways? That’s the trick.

At any resolution there will always be a few hexagonal tiles that will connect to a neighbor twice. However that doesn’t mean the connection is the same: each of these will result in arriving at the new tile with a new rotation of the “forward direction”.

If you build a paper (or cloth) model this will result in a few “pointy bits” in your model. You can see this on the highlighted area of the 3D model of earth. In three dimensions you can also think of when two half pipes meet at an angle, forming a triangular cut. Are these true hexagons? Or like “Parker’s square” they are really just pentagons disguised in the third dimension? It can be a matter of definitions. I would argue they’re not isomorphic to pentagons because the two connections are not identical: taking each will result your pawn is now moving in a different direction.

If you want to try it out for yourself, I encourage you to download this PDF and print (or sew) your own “Gosperahedron”.

All models are wrong, some models are useful. Wrapping the globe (or a soccer ball) in hexagons in this way has been useful to create a rather interesting and novel world map, one that hopefully can help us all understand better the world we live in and our place in it. Maybe that’s what really matters.

Available for printing!

If you want to decorate your (or someone’s else) office or classroom, the poster can be downloaded at hexagonal.earth and printed as large as you like. My goal is more to share a new vision of the world.

"We’ve basically got it all worked out, except for small stuff, big stuff, hot stuff, cold stuff, fast stuff, heavy stuff, dark stuff, turbulence, and the concept of time.” - Zach Weinersmith

Physicists often talk about the goal of finding a “Theory of Everything” that would connect all the current areas of knowledges. How does relativity work in the very small scale? How does quantum mechanics behaves in very hot temperatures? Our knowledge of how stars explode seems completely separate from the engineering of buildings, which is a completely separate field of knowledge on how particles decay and form atoms, which seems like a separate science from the origin of time. However nature seldom has clear divisor lines and sometimes, just understanding how things connect can help us understand better the universe we live in. In 2023, Physicists Charles Lineweaver and Vihan Patel made a beautiful step in that direction by publishing a beautiful paper which despite it’s captivating content, was densely technical and flew completely under the radar for even the most science leaning public.

This post explores redesigns Lineweaver and Patel’s chart and tries to explain each step and expand it. Let’s explore!

Anything that has ever existed can be plotted on a chart, a single image that tells the story of the Big Bang, how space relates to time and energy, a poster-sized document about how quarks become protons, how stars become black holes, how asteroids become planets, and even why hippopotamus can’t float. It’s a whole physics lecture on a single page. Let’s walk through it.

A summarized poster version of this article can be found at triangleofeverything.com

The Powers of 100

The first problem of trying to fit all particles and objects in a single chart is one of scale. The sun, for example, is over 400x wider than the moon, so in any image that the sun appears whole, the moon will be but a pixel. The largest human structures ever built, would also be barely visible when compared to the moon, but absolutely dwarf a human. In animation and video this is often addressed by having a continuous zoom to show relative sizes, but on a static media this is best addressed switching to a logarithmic scale.

$e$

${10}^{-35}m$

We can then repeat the same for the vertical axis, but now for mass. This essentially becomes what is known as a scatter plot representing the relationship between mass and width of all objects. Below we have a graph representing objects from a red blood cell to the largest mammals and large human mande structures like a Soccer Stadium or the Las Vegas Sphere.

The first thing we’ll notice is that almost everything is in the same a diagonal line, with an angle of about 3 to 1. Every 10x increase in width an object will increase 1000x in volume, so objects that are aligned in these diagonals have the same density. And even though objects have different densities, in a log chart these do not reflect much change. The blue dotted line represents the density of water, meaning anything to the right of the dotted blue line will sink into water.

Osmium, earth’s densest natural material, is only 20x denser than water. Helium gas, on the other hand, is about 20x less dense than water. This is why most known objects will fall on roughly on the same line, and this will extend all the way into our sun!

The smallest object on the above graph is the Itokawa asteroid, which was visited by a Hayabusa space probe and successfully returned to Earth, the first probe ever to accomplish that. Then we have the two moons of mars, Phobos and Deimos and Enceladus a small moon of Saturn, believed to harbor a liquid ocean under its frozen crust. Something interesting happens between those last two however, as objects move from 1 trillion tons of mass they start becoming rounder until they are near perfect spheres. This is because the force of gravity overcomes any molecular bonds that keep objects rigid, and at this scale can be basically considered fluid and acquiring a spherical shape. It’s the first requirement to be classified as a planet, like Pluto (albeit a dwarf one).

Small planets and moons don’t have the gravity to hold very light elements like hydrogen and oxygen, so there’s no atmosphere. Larger planets like Earth, Mars, and Venus do, but they exist in a Goldilocks zone: too big, and they hold so much hydrogen that the planet doesn’t have a surface anymore and becomes a gas giant. Gas giants have a solid core, but there’s no set boundary between their low-pressure surface and their dense core.

Stars and Planets

So far all objects on the graph are just following the same boring line: but that starts to change when we reach stars. Electromagnetic forces are what keeps atoms away from each other and the main reason our density line becomes constant. But as mass increases, the force of gravity starts to increase too and at some point, when an object surpasses roughly 50% more massive than Jupiter, gravity overcomes Electromagnetic repulsion and the object starts becoming smaller the more massive it is (this process is called Degenerate Matter). Its center is so dense that fusion starts happening, first with Deuterium (heavy hydrogen) and the object starts emitting energy, becoming a Brown Dwarf—a middle ground between a Gas Giant and a Star.

But once the mass reaches a critical point, where the pressure of the atoms overcomes the repulsion, regular hydrogen starts fusing into helium and other elements, releasing a huge amount of energy in the form of electromagnetic radiation (including light) and that energy starts pushing the atoms apart again. We are now in Star territory.

And while the new energy from the fusion of atoms seems to allow stars to keep the same density line, that process is not as stable as the repulsion from electromagnetic forces. If the fuel exhausts too quickly the object will collapse into a White Dwarf. Even more massive

That object now becomes a star. The future lifespan of a star also depends on its mass: a small star, once it exhausts its fuel, will transform into a White Dwarf, which will exist for trillions of years. More massive stars will enter a Red Giant phase (some as Blue Giants or Super Giants), during which their outer layers expand, engulfing any planets in their orbit. Once the fuel of a Red Giant is exhausted, the star will go supernova and shed its outer layers across vast distances. Depending on what remains, it will leave behind a White Dwarf, a Neutron Star, or a Black Hole. Stars have a size limit; beyond 100 solar masses, they don’t have enough energy to sustain their size and will immediately collapse into black holes.

First boundary of the triangle: black holes

And thus, we reach the first density limit of our universe: the Schwarzschild radius. Once an object exceeds a certain critical density, it will collapse into a black hole. While all the mass in a black hole is considered to be in a single-point singularity at the center, there is a practical radius outside which light cannot escape. This diameter is directly dependent on the mass, which is why the Black Hole line has a lower angle than the isodensity lines we were following before.

But after we crossed the scale of stars, something else interesting happens: as we look at objects on the scale of galaxies and globular clusters, they also fall into a separate diagonal line, also proportional to volume. However, this isn’t the density of atoms as we know it, but the density of dark matter structures. This indicates one of the reasons Dark Matter is so hard for us to understand: its density is less than that of a typical lab vacuum, and can only be observed in very large objects. Yet, it constitutes most of the stuff in the universe. It is possible that there are smaller objects made of Dark Matter, like Dark Planets and so on, but because they’re so sparse, they're hard to detect by the standard methods used to find exoplanets.

The largest structures we can observe in the universe are Superclusters, like the Laniakea Supercluster, in which the Milky Way is located. We can also see large Voids where almost no galaxies can be seen: but they still have roughly the same density as the rest. Finally, we reach the upper limit in size and mass: our own observable universe.

Second boundary: the Hubble Radius

Due to the constant expansion of the universe, there are some regions that are moving away from us faster than the speed of light, meaning that not only can light from them not reach us, but nothing else can either. It implies that there’s no way anything happening there can ever affect us or even be known by us. This is why, despite our universe being truly infinite in size, in practice physicists often use the terms “observable universe” and “our universe” interchangeably. The universe is infinite, but OUR universe is the size of the Hubble sphere.

This brings us to the second side of our Triangle of physical bounds: the Hubble radius. No structure in the universe (the whole, infinite universe) can be larger than a Hubble length, because if it were, one side would not be able to communicate with or affect the other in any way, and therefore it can’t be considered a single entity. The observable Universe, “our” observable universe, is not one, but an infinite number of bubbles, as every star and every point anywhere will have its own Hubble Sphere around it, limiting what it can observe, much like the Earth’s horizon is an individual circle around each observer.

But what about the other end?

Third boundary: the Compton Limit

On the other end, we see objects following the same density line: from blood cells, to microbes, to viruses, to molecules, and individual atoms, all seem to follow roughly the same density as the atoms of which they are made. This is also where we move from biology into chemistry and then into particle physics.

Something interesting happens in the bottom left corner: the darker line represents the Compton Limit. Like the Schwarzschild radius, it’s also directly proportional to mass and not volume, and therefore, in our graph, it appears as a line at a 45º angle to the grid. It represents the size at which Quantum Uncertainty meets the energy level of the particles such that anything with sufficient mass, or small enough size, may spontaneously become a particle-antiparticle pair and annihilate itself. Most of our known particles are in a smaller region at the bottom. Let’s zoom in.

All known particles reside somewhere on the Compton Line. For particles that don’t have mass, we plot them using their mass-energy equivalent from Einstein’s equation (more on that later).

Particles have a complex network of transformations and decays, also dependent on mass. The Top Quark decays into a Bottom Quark, which then decays into even lighter quarks, each time emitting a W Boson in the process. The W Boson, in turn, decays, emitting a Lepton (an Electron, Muon, or Tau) and their corresponding anti-neutrino (or vice versa). Up and Down Quarks combine to form Protons, Neutrons (and sometimes another Meson), implying that the W Boson itself is instrumental in the origin of most known fundamental particles.

Mass is energy which is temperature

As mentioned, that graph is also plotting some massless particles like photons by using the E = mc² equivalence, so our vertical mass axis is also an energy axis. As photons become more energetic, their wavelength decreases, so our horizontal axis for spherical diameters also doubles as the wavelength measure for the Electromagnetic spectrum. You’ll notice that the point at which our atomic density line crosses the Compton line is around the Gamma Ray region, which is the radiation emitted during nuclear reactions, like fissioning an atom. It then goes down into X-rays, ultraviolet, our visible spectrum, and ends in long radio waves.

Energy is also equivalent to temperature through the Boltzmann constant. This means that now our Mass-Energy vertical axis is also a temperature one. Since this is a logarithmic scale, the range from 0° to 100°C, in which water can be liquid and all known life exists, is displayed only as a thin blue line. It also crosses the EM spectrum at the Infrared range: what does this mean? All matter emits radiation in a spectrum similar to the temperature it occupies. This is why all objects at room temperature emit Infrared radiation as heat, and as they start getting a little hotter, they begin emitting visible light. The Sun, which is at much higher temperatures, also emits Ultraviolet, and to a lesser extent (especially in solar flares), X-ray and Gamma rays from its corona.

What about even hotter temperatures? The core of the Sun is even hotter and has enough pressure to fuse hydrogen into helium, reaching 15 million °C or 15MK (at very large numbers, the Kelvin and Celsius scales are nearly identical). Some more extreme astronomical events like giant stars, supernovas, or black holes can reach up to 1 billion K. But to find even hotter temperatures, you'll need to come back to Earth, or more specifically to Switzerland, where the Large Hadron Collider can reach up to 100 TeV of energy, equivalent to over a quintillion degrees Kelvin. At these energy levels, protons and neutrons (the “hadrons” being collided) will “melt” into their constituent quarks, and the less energetic quarks will transform into more energetic equivalents. At the highest temperatures the LHC can reach, it was even able to briefly create the Higgs Boson, which imparts mass to other particles. Such temperature levels were last seen in the universe only a few picoseconds after the Big Bang (unless some other alien scientists have beaten us to it!).

And this takes us to our final leg in this journey across the universe: the axis of time since the Big Bang.

Another axis: density and time

The Big Bang is often visualized as an explosion of something expanding into nothingness, but that’s far from the truth. As far as we can measure (and we’ve done it to an incredible acuracy!), the universe is infinite: how can something infinite still expand? Expand into what? It’s better to visualize it instead as a continuous decrease in density and temperature. The universe started as extremely hot and unbelievably dense and has become less dense and cooler over time. While this progression is not linear, it has always only moved in one direction. Like any gas, as you increase the density and pressure, you increase the temperature. In the case of our universe, increasing the temperature (or more precisely, the “energy levels”) of particles works like turning back the clock to see how the whole universe was in the early moments. We have conducted practical experiments to recreate the conditions of the universe only a few picoseconds after the Big Bang, and our theoretical models can go even further, down to the Planck Scale.

Wait, the Planck what?

Planck Units: a truly “universal” system of measurements

In most forms of measurement, units are defined based on something related to human experience (the King’s foot, the meridian of Earth, the boiling temperature of water), and then the universe’s fundamental constants are calculated based on that and added to equations. Planck Units reverse this logic and instead define both the Speed of Light and the Gravitational Constant as one, and the Planck constant to be equal to the circle constant. In short:

$G=e=1$

This greatly simplifies many physics equations:

$E=mc\mathrm{²}$$r_s=\frac{2Gm}{c^2}$

The Planck units also have physical manifestations and converge at the Big Bang itself, as all of them represent some type of either limit of our model or a transition between them.

The Planck Length represents a limit where the effects of relativity over spacetime and quantum uncertainty about location converge, and making sense of that would require a new theory of quantum gravity. Similarly, our current models cannot comprehend anything that happened before one Planck Time (the time it takes light to travel a Planck Length) after the Big Bang, nor anything at temperatures higher than Planck Energy (which is the energy level the universe was at a Planck Time). All known fundamental particles simply cannot exist as we know them at such temperatures and therefore did not exist at the time. To even address it would require a theory of everything, that would unify all forces, including gravity.

Everything is just condensation

The history of the universe can be thought of as fundamental particles condensing out of the background, similar to how droplets of water condense out of water vapor as it cools, thereby creating new conditions for new composite objects to emerge. Droplets of rain will condense into rain, which collects into oceans that then become the solvent for countless chemical reactions and the required medium for life as we know it. Similarly, Bosons serve as the mediators of fundamental forces and, as the background energy of the universe cools, they emerge out of the primordial soup in different flavors, breaking down the fundamental forces that existed before into new ones.

${10}^{-32}$

As the universe further cooled down and expanded, up and down quarks, joined by Gluons, formed Protons and Neutrons, and then, as molecular bond forces overcame the background energy, they became atoms (the universe was barely a few minutes old and had the density of water). Further cooling meant that the kinetic energy of atoms was low enough to be overcome by chemical bonds, allowing atoms to form into molecules, and then for these atoms to condense into stars and planets (this took about three to four hundred thousand years).

During those multiple phases, the universe had different densities and was dominated by different forces (like radiation, matter, or dark energy). In our chart, we can imagine the universe's expansion as a diagonal line going from the left to the right, leaving composite objects in its path. The current density of the universe is roughly the same as that of objects we know to be mostly made of Dark Matter, like galaxies, clusters, and voids.

Searching for Dark Matter

We know most of the universe is made of it, yet we don’t know what it is. However, we have been searching for it long enough to know a lot about what it is not.

It’s possible that it's not some new particle requiring new physics, but rather just something made of the particles we already know of, like Hadrons, Quarks, and Leptons. We’ve searched for it using Gravitational Lensing with both earth-based observatories and space-based ones. If Dark Matter were just made of hard-to-detect stars or lots of rogue planets, we’d have seen it by now.

We also looked for dark matter in the mineral layer of the Earth, knowing that if it was smaller than a few grams, it would have left a mark there. We didn’t find any there either. There’s also a separate line, proportional to the surface of the cross-section and its mass, that would have left some holes in the Cosmic Microwave Background. We looked, and it wasn’t there either.

Meaning that if Dark Matter is made of large objects of stuff we already know, then there’s a specific region where it would be found. One such candidate would be Primordial Black Holes. These are Black Holes formed not from the collapse of stars but from remnants of small fluctuations in the fundamental plasma in the very early moments of the Big Bang. If they exist, they would have masses between a small moon and an asteroid, with a Schwarzschild diameter between micro and picometers (the size of a proton). Larger than this and we’d have seen them in our Microlensing experiments, and smaller than that, and they would have already faded away due to Hawking Radiation.

Or, of course, Dark Matter could also be a new fundamental particle requiring some new physics. If that’s the case, then we also know where it should be: mostly because physicists have been running experiments looking for it – and failing to find it – for many decades. If Dark Matter is some sort of WIMP (Weakly Interacting Massive Particle), then it should be found somewhere between 1 and 50 GeV.

In science, failing to find new data is still new data. In the 19th century, scientists spent decades looking for an entity they called the Aether, which would be the medium for light, by trying and failing to measure the difference in the speed of light in the direction the Earth was moving. All those experiments always led to a result of zero, with increasingly more decimal places.

This inspired Einstein to think about what it would mean if the speed of light was indeed always constant, regardless of the direction of travel, and the result was the Theory of Relativity, which redefined Classical Physics (back then just called “Physics”) for very high speeds. Maybe this is what’s happening, and we just need to adjust our Gravity equations for very large objects? However, this possibility has become increasingly unlikely as we have found galaxies where the center of mass is not the same as the center of mass of the visible stars, suggesting it’s not just a miscalculation of gravity but rather something separate from regular baryonic (non-dark) matter.

The Far Future

${10}^{-30}g/L$${10}^{100}$

The end

On that note, we end our journey. What started as a simple density plot became a story of the universe’s past, present, and future, a map of the things we know, an indication of what we know we don’t know, and maybe where to find those we don’t even know we don’t know.

A print version of the main poster can be found at triangleofeverything.com

References:

• All objects and some questions, by Charles H. Lineweaver and Vihan M. Patel (Am. J. Phys. 91, 819-825 2023))

• Macro Dark Matter, by David M. Jacobs, Glenn D. Starkman, Bryan W. Lynn (arXiv:1410.2236)

• Dark Exoplanets, by Yang Bai, Sida Lu, Nicholas Orlofsky (Phys.Rev.D 108 (2023) 10, 103026)

• Credits for illustrations used: NASA, ESA, Hubble and artists from Wikimedia Community: Ivanov, Pablo Carlos Budassi, SounderBruce.

The goal with this program is the following:

• Combat voter apathy. Reaching the required quorum of 1M ENS votes for an executable proposal has become harder. We believe this happens because of governance fatigue, where large delegates often get tired of monthly voting. Thus rewarding responsible delegates as well as having new ones should help.

• Increase decentralization of power responsibly. Right now the current distribution means that 6 top delegates could agree to execute any proposal.It also means that the largest delegates could stop bad proposals being voted, so they’re also a line of defense. It means distributing power should not be done for the sake of redistribution, but responsibly to parties we believe have a long term interest of ENS in mind, as well are philosophically aligned with the goals of web3

• Create more aligned third parties with the ENS ecosystem. We believe the more we can have serious parties, who have a stake in the future of ENS, the bigger the reach and long term stay our technology will have.

• Combat stagnation of voting power. We believe that while some continuity in the work of previous stewards and other parties is good, it’s also healthy to bring new voices in the ecosystem and all of that starts in the voting power distribution.

Amounts and vesting

These are the current hardcode limits for ENS governance:

• To propose a social vote on Snapshot: 10K ENS

• To propose an executable vote: 100K ENS

• Quorum needed to execute a proposal: 1M ENS

The equivalent monetary value is volatile: ENS at its launch was briefly at $50, then for many years stayed in the $6-$12 range and recently has gone up again to $25. We believe that the best way to detach governance decisions from monetary value is with multi year vesting. So all our ENS distributed in this program will be streamed using Hedgey, which will permit the receiver from having immediate voting power, but they can only access the monetary value over the 3 years as a stream.

The only exception will be Steward compensation for term 5. Due to the limits of rule 4.8 on Stewards ruling on their own compensation, we can only recommend the stream to be applicable starting on term 6 and beyond. Term 5 ENS compensation will follow the manner in which was defined by metagov term 4, distributed in two tranches at the end of each semester, in June and December. It’s effectively similar to a 1 year vesting.

Stewards

Maintaining previous compensation, all stewards are eligible for 10k ENS over the full term, paid at the end of each semester. This has been done in previous years and was always listed on the metagov budget. In order to increase this transparency, we also commit ourselves to start doing a more longer process of campaign and outreach to new steward candidates, both to get more quality candidates in the candidate pool, but also to make sure they are widely known by the community before the vote. This will be detailed later.

ENS Stream Providers

As people who have been working deeply into the ecosystem building tools for it, we believe developers who are participating in the Service Provider payment should have a vested long term interest in ENS and a larger voice on its future decisions. To ensure that the decisions are not centralized in companies but rather on the people working on them, ENS will be granted for Individual developers, NOT the companies themselves.

Each participating company will have the option to elect one representative for each 100k USDC/year of their current budget. So a company receiving 300k per year will be eligible to indicate 3 different persons, who will receive 10k ENS vested over the next 3 years (with immediate voting power). These persons must be employed in the company and involved in the day to day decisions, development and outreach of ENS (but there’s no requirement they be doing direct development or technical work).

Delegates

Being a delegate is a big responsibility that requires time commitment which is done voluntarily. Many of the top Delegates have voting power not because of individual ownership of ENS granted at airdrop, but rather the decision of small individual Airdrop receivers who have delegated to them. Because these votes are seldom redelegated (despite campaigns), it means that a person who was a delegate candidate in 2021 might be stuck for the foreseeable future with the responsibility of decisions for many voters without any compensation.

As such the Metagov Working group proposes picking 3 delegates who fall under the following criteria:

• Have voted on most of the snapshot votes in the past 3 years

• Do not already qualify on the two criteria above, as either steward or stream provider

• Their voting power is a representative of a large amount of individual delegations rather than just holding lots of ENS themselves (we understood this could be gamed by an individuals distributing their own ENS in multiple accounts, but right now we have no reason to believe it applies)

• Have shown responsible and thoughtful voting. How they voted should not matter, just the fact that they are share their thinking and engage with debate, etc

The exact process for this selection will be detailed later. The selected delegates will be compensated with 10k ENS each, with a 3 year vesting and immediate voting power.

Besides these 3 delegates we will also commit to distribute another 30k ENS through snapshot “incentivized voting” feature, over the full year. The exact process for which will be detailed later.

Other Companies and groups of interest

Metagov Working group is also interested in identifying other parties that would benefit from the program. We hope to find 3 to 5 parties that match the following criteria:

• Are building a large product with ENS at the core of their business, or participate in other organizations who would make sense to be aligned with ENS

• Are aligned with the overall philosophy of Web3, distributed applications and permissionless networks

• Are not already large holders of ENS

Conclusion

With the current distribution plan, Metagov would be distributing about 550 thousand ENS to over 50 different key parties, all who are considered responsible and important partners, who would then be aligned over the long term prospect of ENS.

This is just a preliminary temp check to see if the community agrees with the direction. Numbers, dates, amounts, and even criteria are subject to change, and the total amount is not even completely funded by the current metagov budget.

I’d like to discuss different approaches for how to handle this in the future. Since the cutoff date of December 6, 2021, when EP3 amended the airdrop to include accidental returned funds, there have been 21 accidental transactions to a total of 16 different accounts. As far as I could tell only one has been refunded manually from the Metagov Safe.

Here’s a summarized table:

* requested funds back

It’s important to note that the 3 largest transactions account for 60% of the total. Of these listed, only two have reached out to us asking for the funds back and only the second, asked last year, has received it. User @tman64 has made a request for his funds, which prompted this study. We can safely assume that these are not the only people who would like their money back and that there others who never bother to contact us – or never managed to find out where to do it.

Finally, if you read the account of the user @AlexW we can also get some context on how these accidents happen. In his case he was sending from his exchange account into his newly set up Metamask, but he didn’t know how it worked and thought the ENS address listed on the wallet was actually his own “ENS deposit address”. We should assume that many of these accidents were also sent from exchanges (we can even see two known coinbase and one Paribu address on the list) and are probably from users who cannot execute transactions nor necessarily receive the money on the address.

So what are we to do as a general policy? Here’s what I see are the options:

1) Do nothing and wait for requests

We could simply keep not doing anything and acting on requests on a case by case manner. Metagov would send ENS for @tman64 and then maybe create a more formal ENS request process later.

It’s the natural inertia action, but it would mean that many users who lost coins would never see them until they found their way to the forum.

2) Multisend send all back

We could simply send all these tokens back to the address they came from. This option would be expensive (according to Multisender app calculator it could cost maybe 7 full ethers which is more than the value of the tokens being sent) and not necessarily reach the intended audience. Tokens sent back to the general Coinbase account are not credited to the original recipient, and either end up lost locked up on an accidental address (again!) or are just a donation to Coinbase.

3) Airdrop them back

A second option would be to create an airdrop, which is a lot cheaper for the sender (but still pricey, Multisender quotes at lease 0.5 ether to do it). It has the advantage that it only sends tokens back to accounts that can prove they actually own the address. On the other hand that would indeed exclude many newbies who sent it via exchanges and would have the same issue as option 1, in which if you’re not aware of the new airdrop, then you’ll never know you have the chance.

Personally I started this research based on the post by Tman64, thinking there ought to be a better way than to wait for forum threads to send money back, but honestly it might be the case that there isn’t. These accidents are common, but not common enough to merit a new process, and any alternatives to send automatically will be very expensive or exclude exchange users. Maybe the process can be marginally improved by having a proper form where people go and submit their request, but maybe not even that’s worth it.

Whats your opinion?

On Voting Strategy

The voting system is an approval voting. The reason we did not pick something like Range, Star or Ranked Choice voting is mostly because these are not yet supported on Snapshot (Snapshot does allow Ranked choice, but then you must rank ALL candidates, which doesn’t really work with such large amounts of candidates). That does mean that as a voter with a lot of weight I need to think more strategically. On approval voting, approving all candidates simply pushes the baseline up and results in the same as not having voted at all, and it means that if you “approve” on candidates that are already ahead it might hurt other candidates you prefer but that haven’t made the cut.

So I will put my vote in separate sections of support which are a way to express my uncertainty regarding which of those I will actually put on the ballot.

Strong Support:

Blockful

I’ve met Alex Netto on a workshop at EthBrazil 2022 when he was still a student. We then started collaborating on ideas on how we could improve the ENS base contracts to save gas and improve the user experience by doing single-transaction registrations. He surprised me in all aspects. I’ve seen him drop out of university to create a small dev shop dedicated full time to blockchain development and I’ve seen it grow to a 9 people team, doing mostly ENS related work. While Blockful never had a “product” release, they have been involved in developing smart contract work for Namehash and many other clients. I have 100% confidence that they will deliver a great value for their $300k.

Namehash

I have been following Namehash development closely for over a year and was lucky enough to have a demo of their ENS registration website last year and I was blown away. They are also doing the smart decision to make most of their innovations for their website into modular libraries that others can use, like NameKit and NameGuard, meaning that great experience can be integrated into many other apps. Whenever I pick a project, I ask myself if that team could push ENS forward on their own, if a meteor struck all other teams: I have no doubt that Namehash could.

Resolverworks

Slobo.eth has been an incredible steward for ENS and I have been following his work since Nftychat, an attempt at making ENS the core of a social messaging platform. While his proposal is the most expensive of all the asks, I think it’s worthwhile.

Support

This is a section for projects that I support, but for which my vote might depend on external factors, like which projects are more likely to win.

ETH.limo

While we always talk on how ENS was created to replace 0x134.. address types into more readable names, hashes for content, like IPFS or Swarm (for which we had integrated early versions way back in the Mist days) were as important as the names. While the vision for a fully decentralized web – where devices access content not by going through a central server, but by downloading it in a P2P fashion from other devices – seems to be less fashionable, I still believe in that vision and hope to keep supporting the pieces that will make it possible. And Eth.limo is such important piece. One criticism I would make on their proposal is that it seems much more focused on supporting the current eth.limo infrastructure rather than building news tools that will increase the adoption and support of decentralized websites.

Unrugabble

Premm.eth is a great member of our community and creating support for L2 names and Account abstraction is very important.

Wildcard Labs

Stevegachau is a long time ENS contributor. They have a good track record, and they have a very decent ask for the value provided.

ENS.Vision

ENS Vision is the second largest ENS domain registrar so it makes sense to support them. Their proposal is however about Forge, a single product which is interesting but of limited use for the ask price. And after their very softball interview with the CEO of Unstoppable Domains, I would love if they clarified their position on UD collaboration.

Projects I support but don’t think fit Service Providers

There are some great projects that are Service Providers Candidates. However I don’t think they fit what I believe is the goal of the Stream selection, which is to pick great teams that can improve the ENS system. Instead, they are great projects on their own that either support or promote ENS in many ways.

The following projects are ones I would strongly encourage the new Ecosystem stewards to add as candidates for grants (not necessarily in the requested amount) but for which I don’t think are good fits for service providers.

• Tally

• Ethereum Follow Protocol

• Gnosis Guild

• The Interceptor

• Wayback Machine

• Unicorn

• Alphawallet

Unsure

Namesys, 1w3, ESF and Handle are projects that on the surface seems interesting although much of the proposed work intersects a lot with what other teams are also proposing. As mentioned, in an approval voting system, giving away too many votes dilutes your own voting impact and can decrease the chances that a project you prefer will be selected. I will commit to make deeper look on their proposals to make a decision.

Remaining

I would prefer not to criticize projects in this post. The remaining projects are some who vary from "looks like a good but there are other better teams building similar stuff" to “I don’t get that at all”.

First of all, how much money has the DAO received so far?

Money In

There are multiple ways to tell this story, measuring value in ether, or dollars, at the current time or then. The method I will be using will be to account only for USDC, ETH (and WETH) transfers and measure them at the day of the transfer.

Almost 100 million dollars. That’s taking all the ether and USDC transactions coming into the address wallet.ensdao.eth at the time of their transfer. That of course doesn’t tell the whole story: it ignores all the ENS tokens it holds (valued at over 90 million right now but of course that would change if the DAO tried to sell much of it) and because lots of these were transferred in ether then that total value is also relative.

Most of the money came originally from the old registrar controller. But both the old and the new still have a large income of money. Here’s the current incoming flux of ether for the new and active registrar controller:

You can see that the Registrar controller has an incoming flux of roughly 30 thousand dollars per day, which amounts to almost a million dollars per month! And that seems roughly stable, despite the variations on the larger NFT market.

Money Out

Now if we measure all the outgoing transactions, then we see that the DAO transferred out almost 70 million dollars and still has 16 to spare in its wallet (again, not counting ENS tokens).

Endaoment and ENS Labs

Most of that money has been sent to the Endaoment, in two tranches. I am also ignoring a large transfer of 10k ethers made to Cow Swap (as per EP3.3) because it also had a corresponding incoming transaction of equal value. You can follow up the Endaoment composition on this Dune Dashboard.

The second largest slice is the “unspent” portion which represents $16M still on the wallet (this adds ether and USDC so it varies).

The third largest slice is for ENS labs, here represented by the address coldwallet.ens.eth as “ENS Labs Cold Wallet”, which is the target of the receiving stream of that was approved in EP14.

To clarify, EP14 was $4,197,500 for the year 2022, but more importantly it approved a stream of $11,500 daily to ENS Labs, which can be revoked at any time by either party. Here are all the transactions that sent USDC from ENS DAO to the ENS Labs wallet:

Working Groups

Here is the budget of the working groups broken down.

First of all, for all it’s governance overhead, it’s important to note that while most of the ENS governance calls are related to Working Groups budget and steward selection, that they all combined have received about half of what ENS Labs have and a fraction of what is sitting unspent on the wallet.

Second it’s curious to note the sheer amount of transactions sent by these groups, transactions under 100k are not even listed otherwise it would be extremely busy – and 100k is a lot of money!

Also a third point of note is that by far, the largest line item on each group is actually the money they did not spend. In all cases, they have remaining in their wallet more than they have sent to any individual address.

Ecosystem is the largest working group and most of its largest line items are actually sending to other contracts who then forward it elsewhere. Like the Small Grants or Gitcoin grants, these are just ways to offload the governance of funds to other entities, like Gitcoin or the Small Grants program.

Ecosystem stewards provided me with even more detailed categorization which allowed me to put this tree map chart of money flows

It’s important to note that money out is not an expense: I have not tracked the funds inside the pods, how much they were sent out and how much of them remains in the pod (which are still in control of stewards)

Metagov on the other hand has larger individual line items. The biggest is Karpatkeys fees, paid to manage the sizable endowment. Notice these are only tracking “transactions that were paid” for the total life of the DAO: fees incurred and not yet paid, or expenses accounted for but not sent, etc, are not shown. The third largest slice is the Governance Pod which was listed as the “governance” line item in the working group’s budget. I am still clarifying what it does and what its purpose.

Public Goods is the smallest group and it reflects on smaller checks. Its largest check was sent to Gitcoin and the second largest is the the Scholarship program, where it selected 6 ENS scholars all over the world for a yearly stipend of $1000/month in a super fluid stream.

Community working group is a defunct group that was abolished after one term and sent the remaining funds to ecosystem.

Some conclusions:

DAOs can be a great tool for financial transparency as every cent that the DAO can spend has to be accounted, approved and can be transparently audited on chain. But of course, in order for that to work we need to actually look at it.

• Large amount of small tickets It’s interesting to notice the large amount of small checks in the groups. On one hand it means that the groups are doing a good job spreading funds through many different initiatives. On the other hand, a large amount of small checks can be harder to audit and it also means that a group that has a significant contribution to ENS as developers don’t have the chance of getting bigger funds in similar scales as ENS Labs has. I hope to expand that point in a future point.

• Unspent funds Most working groups have a large amount of unspent funds. I believe these should be taken in consideration when making requests for new funds. For example the Ecosystem working group is requesting 400k in new funds while they are sitting on over 600k unspent in their wallet.

• Auditability tools I’ve done this analysis by downloading the data from ether scan as CSV and playing around in Numbers. Ideally we should be able to build Dune Analytics dashboard and other visualization tools that help visualize these. For example, while the ENS Labs stream has been approved in a vote, I had not seen the full usage of funds until now, and I don’t believe there’s any working dashboard for it.

• Possible warnings I believe that exercises in using on chain data like these are important defense mechanism for the DAO. As more money keeps flowing, we need to make sure all the data is auditable and we have the right tools to make sure the funds are being properly allocated.

The problem with maps

Beyond their practical applications, maps serve as a representation of our perception of the world. Even before Mercator introduced his infamous map projection, a famous map found in Da Vinci's personal library (though authorship is disputed) depicted the world in a four-leaf clover format, which in turn might have inspired the cartographer Cahill. In 1909 he published a world map that was later expanded upon by Waterman in what came to be known as the “Butterfly" map. It portrays the world as a set of wings spread out in an impressive arrangement.

Later, in 1943, Buckminster Fuller introduced the Dymaxion Map projects the globe onto an icosahedron. This model can then be unfolded to depict all continents unified as one landmass, a concept Fuller coined as Spaceship Earth. Intended for educational purposes, it was designed to be assembled as a puzzle by students, thereby enabling them to create their own vision of the world.

While the Dymaxion Map is celebrated for its minimal distortion of landmasses and its striking visual appeal, it has also faced criticism due to its jagged coastlines and seemingly inelegant whitespace.

Videogames present another interesting domain where different types of maps are experimented with. When YouTuber PippenFTS embarked on a collective project to reconstruct Earth in a square grid within Minecraft, they opted for a Dymaxion projection but modified it to give the Americas a more traditional north-south orientation. The game Civilization employs a hexagonal grid, but its maps are cylindrical rather than spherical, with inaccessible poles and sides that wrap around. Its "real earth map" uses a custom projection that deliberately enlarges areas of high player interest, such as Europe, North America, Japan, and the British Isles.

A better grid

The square grid is by far the most common: it’s simple to build and can be subdivided into identical squares. Given that all their neighbors are equidistant, hexagons facilitate a more accurate approximation of distances, areas, and radii. While hexagons can be divided into smaller hexagons, they don't fit precisely within the parent hexagon, resulting in distortions.

For instance, Uber employs a hexagonal grid for storing and analyzing geographical data, allowing for multi-level hierarchical data sampling. Uber’s world map draws from Fuller's icosahedral division of the world. However, since an icosahedron cannot be tiled purely by hexagons, it incorporates 12 pentagons at every level. At its highest level, it uses 110 hexagons to encapsulate the globe, each of which is subsequently subdivided into seven smaller hexagons. Each pentagon is further divided into five hexagons and one smaller pentagon. Because child hexagons don’t fit perfectly within parent hexagons, a given coordinate could fall into different hexagonal parents, depending on the resolution level. The H3 grid system is never meant for the end users and therefore they never attempted projecting the word in a single flat image.

While H3 serves Uber’s data analysis purposes efficiently, it may not be as useful in other contexts: it cannot be neatly unfolded onto a flat area, and if you're developing a hexagonal game or simulation, the unavoidable pentagons pose a problem.

A potential compromise between both grid systems might be the use of a fractal known as Gosper Island, which forms the border of the Gosper Curve or results from subdividing a hexagon into infinitely smaller hexagons. But can you tile a sphere with it? Not without some compromises.

A hexagon can be folded into several polyhedra, provided you're willing to accept certain concessions, such as allowing a few hexagons to connect to other hexagons in more than one way. While some might argue that this makes them isomorphic to a pentagon (or in reality, an octagon, since in this shape two of these special edge cases always come in contact), the crucial point is that they can still be simulated and folded as hexagons.

A Rhombic Dodecahedron—the shape derived from spheres arranged in a hexagonal grid—can have its faces divided into four groups of three rhombi, collectively forming a close approximation of a hexagon (Fig E). This structure can be unfolded into a central hexagon surround- ed by three others, matching the initial hexagonal subdivision of our fractal. By subdividing the Rhombic Dodecahedron in this manner we achieve a new polihedra with fractal faces we are calling the “Gosperahedron” (Fig F, G).

I haven’t been able yet to define it more properly other than constructing it with some degree of error in my methods but by folding it in paper it’s clear that the shape accommodates the Gosper Islands very naturally. One interesting aspect is how the “edge cases” of the two hexagons that connect to each other twice are always at 90º angles from each other, allowing the faces to connect like two cillynders connecting at each other with a 45º cut.

A beautiful new way to see our planet

Fuller's Dymaxion map was envisioned as an educational tool—a classroom puzzle—challenging students to create their own map projections, centered as they wished. By using a Gosper Island to project Earth onto a Gosperahedron, the puzzle can be simplified to only four pieces. These pieces can be rotated into various configurations, enabling students to more accurately compare areas, distances, and traversal options on the globe.

The map above displays multiple configurations of a projection centered on the North Pole. The representation of areas and distances is consistent, exhibiting minimal distortion. To illustrate how they connect to each other, the Oceania, Africa, and South America pieces are replicated. By rearranging the pieces, a similar map can be produced with any continent at the center.

A more impactful view can be achieved by relinquishing the conventional orientation of continents, instead aiming to portray Earth as a single island—the "Spaceship Earth"—which humans have gradually discovered and navigated.

More to explore

Geocoding: Any location on Earth (or the sky) can be referenced by a unique index, based on either the Gosper Curve (Fig H, I) or the H3 binary index. This index can be represented numerically or textually, providing an open-source alternative to systems like "what3words."

Planetary-Sized Simulations: The fractal nature of the indexes facilitates the creation of simulations or games on a planetary scale for scale-independent phenomena. The system accommodates variable resolution; areas of high interest can be rendered in finer detail, while less relevant areas can be simulated at a coarser resolution. At the boundaries, computations are performed at the level of their parent cells, recursively reducing in detail until, for areas of minimal interest, simulations are computed for just a few very large hexagons.

Spherical Imaging: This offers an easy way to store spherical images and videos in a two-dimensional square format. Fractal indexing can enable progressive resolution loading based on bandwidth requirements.

The Earth as a Puzzle: This unique projection enables Earth to be represented by four separate Gosper tiles. These can be rearranged in a classroom or board game setting to help students understand a 2D projection that maintains area and traversal relationships between continents. All hexagons on the ap represent the same area and distances, helping them understand how big and how far things are. By rearranging the pieces, students can gain a better understanding of the distances between areas, including those across the poles.

Download a summary PDF version of this article

If you liked this, feel free to reach out to me at avsa at ethereum dot org, or follow me on avsa.eth.limo on Bluesky

It's not China's CDBC, but rather a model I predict that will be copied all over the western world.

First, a context: Brazil is fast to adopt new technologies. Everyone already has phones, social media accounts and WhatsApp. Also, Brazil is already a pioneer with digital payments, being the second largest market of digital transactions behind India.

Pix, launched in 2020 was adopted much faster than digital payment platforms anywhere else in the world. You can go anywhere with just the phone and assume it will be accepted, even with informal beach vendors.
(sorry for the pic quality)

Brazil's "Digital Real" will be launched by 2024. It's a hard deadline because that's when the Central Bank's president term ends and he made that his top priority. With Pix and open Finance already launched, he wants to make sure his legacy is digitalization.

How does it work? Well it's a sort of compromise that is not intended to be revolutionary, rather it's purposefully built to make sure that it is welcomed by the same players of the current system. It's pragmatic, but also innovative.

The goal is NOT to have end users have a digital wallet, but rather focused on financial institutions. It would use Hyperledger Besu (a Consensys developed Ethereum implementation for private networks) to act as a the famous "settlement layer" between financial institutions.

It would be a PoA network: the Central Bank would basically issue licenses to run validator nodes, but it's open to issue those licenses to any bank, fintech and even other civil society organizations.

It has a strong focus on privacy, but not like you expect: since banks are running it, they want to make sure their own transactions are shielded from other banks.

It means all transactions are private and if the government wants your data it must get it via a court order.

The goal is to replicate the same legal structure of the current system, just more efficiently. There is no "government controlled button" on the people's wallets – at least not any more than they have today.

But the interesting, is really how it enables NEW applications.

They're dead serious about it: besides working with Consensys' Besu they have selected Aave as one of their development partners.

One of their stated goal is to make this local network 100% compatible with the EVM ecosystem and to bridge to it.

A more long term goal is to adopt the Ethereum standards to create standardized financial (and non financial) instruments: emit national bonds as tokens, to have official land registries using NFTs, to have public universities issuing NFT diplomas, all on the national chain.

They are fans of DAOs, NFTs, AMMs and all the Ethereum ecosystem innovations, and want to bring them to the national government.

One national chain for everything, ran by multiple nongovernmental institutions. Not revolutionary, but quite evolutionary in my opinion.

(got a new keyboard and it keeps replacing Ethereum with Ethereal and Consensys with Consensus, so sorry for all these typos)

Often the rebuttal is “There are better systems, but Condorcet is too complicated for a general audience”. I want to challenge this notion here by trying to explain visually a series of Condorcet compliant systems, as they would be explained to a live audience during multiple phases of an election: polls before election, a running count during it and the analysis and explanations of the result post the count.

The goal here is not merely to educate voters on how a particular system works in general, but to try to find a self explanatory visualization that could be used to show the current result of a vote.

RCV vs IRV vs Condorcet

First some short definitions:

• Ranked Choice voting is a system in which you rank candidates by the order of your preference

• Instant Run off voting, is a specific counting algorithm that takes those ranked votes and spits out a winner. There are many other types of similar algorithms

• Condorcet is not a specific voting system but a feature of voting systems that states that the if there’s a candidate that would win against all others in a 1:1 round, then that candidate should be the winner, and if there’s a candidate that would lose against all others that it should never be the final winner. IRV does not guarantee that this will be the case!

The first problem here is how precisely one can visualize the state of all voter’s preferences. Because of the very nature of the Ranked Choice, if there are N candidates then there is at least N! ways a voter can rank them (more if voters can decide not to rank all candidates or rank candidates in equal positions). Meaning that if there are 5 candidates there will be at least 120 different ballots, if there are 10 candidates there are over 3.6 million possible ballots!

Probably the best way to visualize the whole race is not to try to show individual ballots but to break down on specific preferences as “different races”. Which is a great because it also happens this is the first step in any Condorcet system. If there’s a candidate that beats all others in a one to one race, then in any Condorcet compliant system that candidate should be the overall winner. But what if there isn’t? That’s where it gets interesting.

Condorcet systems explained simply:

Condorcet are often considered the fairest of voting systems, but are also considered complex and hard to understand. Often because wikipedia articles about it are filled with arcane high magic pentagrams and complex formulas. I hope to challenge that notion.

As a UX designer I also felt the need to test these out, and therefore I used Usability Hub to show the tables of results you are about to see to 40 random users (without any explanation on the methods). Then I asked them to explain how they thought the winner was selected and had them rate each of them in a fairness/clarity score.

Shulze Method

While no country has yet to implement Condorcet methods on their elections (except a few cities in specific referenda), Shulze has been used extensively in many boards and associations and tech organizations like Ubuntu, Wikimedia, Haskell, Kubernetes etc. It’s also a very complex black box, that uses the concept of “heaviest paths”.

An easier way to visualize it would be a rank of rankings. After ranking all pairwise preferences, you sort all possible rankings by the amount of votes that would support that position. In that particular example Charlie is always on the bottom since it has been beaten on all races. But there’s a cycle of winnings between Bob, Alice and Donna. The way Shulze resolves this is to add all votes that would support a full ranking. So the ranking Alice > Donna > Bob > Charlie would be supported by the votes of all people who ranked Alice above Donna (1.8M), as well as all the votes that supported Donna above Bob (1.7M) and Bob over Charlie (2.2M) but it would NOT include the pairs Bob over Alice (because it would contradict the ranking) nor Alice above Charlie (even thou it supports the ranking, indirect links are not counted in the algorithm).

Shulze is, in the opinion of this graphic designer, a hard to describe black box that simply says “trust the algorithm”, which is why it’s so often used in tech companies that, by their own nature, trust algorithms. It’s also probably why Condorcet methods have such a bad reputation as hard to comprehend.

It also rated really bad on the usability test, with most subjects not being able to really understand how it worked. It was rated 2.6 out of 5 for clarity and fairness.

Ranked Pairs Explained

Ranked Pairs is a little bit easier to visualize than Schulze, but it still is complex. You rank all pairwise races among each other and start making the rank from top to bottom until you find the only possible graph possible to draw, skipping any contradictions.

Ranked Pairs did fairly well in the Usability test, being ranked second on the Clarity/Fairness scale but even thou people felt confident to explain it, many still had misunderstandings.

Minimax explained

Minimax is a lot easier to visualize and understand. You rank all candidates by their worst defeat and pick the one where the least bad one. While it’s guaranteed to always pick a Condorcet winner if there’s one, if there’s none then it might result in picking a Condorcet loser! In this example I’m showing how you could have a candidate that lost all races and yet was the winner.

For some, it might also feel unfair or lopsided to pick the least worst, but in a way this is precisely the point of the Minimax method: it’s not about picking the most supported candidate but the least rejected. It’s easy to visualize and understand, but it could be seen to be also very unfair and suboptimal.

In the usability test all subjects could explain it with no problem, by just looking at the above image. However it ranked third in the fairness/clarity score, probably due to the fact that many didn’t feel it was very fair (in the test it was the same score for both).

Copeland Explained

Copeland is probably the most familiar and it’s so common that most people have been exposed to it without ever realizing it or even thinking of it as an election system: it’s often used in sports competition. In Copeland, you separate all pair wise races and add a point for each victory (in some systems there’s also a separate score for a tie or a negative score for a loss). Whoever has the most points wins. It seems simple and straightforward and if there’s a single candidate that wins all races it’s guaranteed to be picked, and if there’s a candidate that lost all of them it’s guaranteed not to be picked.

Copeland doesn’t have a proper system for ties, but this is often solved by using Minimax or simply the average Score of each candidate. While Minimax might feel unfair being applied to all candidates, as a tie breaker it feels fundamentally fairer.

In the usability tests, being shown just the image above and no other explanation, all subjects were able to very easily explain how it worked and it scored 3.6 out of 5, the highest for clarity and fairness.

Conclusion

Condorcet methods are highly considered among academics but rarely used in real elections, due to it being considered too complex and hard to understand. Often states and cities that change to Ranked Choice voting adopt the Instant Run-off mechanism by default, but IRV is also very hard to visualize and can have chaotic and surprising results, which is not what you want from an election.

Condorcet Pairwise rankings is also the best way to visualize the current state of all votes. While an election with N candidates will have N! possible ballots, it will only have N×(N-1) possible rankings. When considering polling situations (or even lessons learned for the next election) it’s a lot easier to think about what factors could change: in our current example it’s clear that if Bob wants to stand a better chance of winning, it should focus on how it compares not to Alice, the winner, but how it fairs among supporters of Donna, which is at third place. Bob doesn’t even need to win all of Donna’s voters: if just a 5% of them start seeing him in a more favourable light, then Bob would rank higher than Alice in the Minimax tiebreaker. If the tiebreaker was average score, then the result is the same: if Bob wants to win, just focusing on diminishing his overall rejection among other voters would be enough to tip the scale.

After running these little experiments it’s been my opinion that Copeland is by fair the most fair and easy Condorcet method, specially when used with Minimax. It’s so easy to understand that it requires no other explanation than a simple table of results. It’s no wonder: billions of people are often exposed to Copeland style competitions and have no issue understanding who is ahead on a given ranking, because it’s used in sports everywhere.

Much has been written on the failures of “First Past the Post” (the american presidency system) and the Two round systems (common in south america, asia and europe), not so much has been written about the failures of IRV, which has been recently started being implemented in Alaska and New York City and other places.

Wait, isn’t Ranked Choice Voting and Instant-Runoff Voting the same thing?

No! Ranked choice is how the ballot is presented. Instant runoff is how the ballot is counted. Ranked Choice, can be a great way to express voter’s preferences and it depends heavily on the context (Approval voting and score voting can be perfectly appropriate depending on your goals too). Instant Run-off is specifically how you take these ranked ballots and find a winner.

Ranked Choice is often promoted as a way to eliminate strategic voting and extremism in elections by picking a moderate candidate that appeals to most people, even if they were not the most popular first choice. While this can be true of ranked choice voting, it’s definitely not the case on IRV, as you’ll see below.

Voting needs to be simple to understand and predictable

It’s not enough that voters be educated how a voting system works. It must be simple for them to understand the current state of all voter’s preferences and the result should be obvious and intuitive. And it goes deeper than just announcing the winner, as votes have many stages:

• Before the election: Polling is a very important part of the election. It’s where voters can understand how everyone else besides them think and how likely each candidate is to win. It helps everyone think strategically, not only on who they’ll vote, but what any given candidate needs to do, and who they need to talk to, to win

• During the election count: during the count (even if it’s a fast electronic counting system) it’s crucial that voters be informed on the current state of votes, when a candidate still has chance to turn the game around and when a candidate becomes mathematically elected. Surprises in an election count lead to less trust in the system.

• After the election: the clear state of voting is essential for legitimacy of an election. If there’s a surprising turn of events, all voters must be able to understand what exactly happened, and not simply be asked to “trust the algorithm”. It’s also important as lessons learned for the future: which constituencies should be addressed on the next election, what the losing candidate could’ve done to revert the game.

Instant run-off voting is the opposite of that. It’s unpredictable and extremely hard to visualize the current state of all votes.

Let’s try a similar example as before. If we were to have show a poll of the first choice between these four candidates we might see something like this:

It seems Donna is on the lead, but this graph doesn’t show anything about second or third preferences. We could add them like this:

This chart clearly paints a different picture! While Donna is in the lead as the first choice, it barely has votes for second choice and very few votes for the third choice. It’s unlikely that she will win this election. But you can’t really tell who would, because this chart doesn’t tell you how the secondary preferences are distributed.

Another option is to present the calculated end result of the polls, often in an animated version that will show you some information like this:

This does a much better job at showing the result, but not much about the state. It tells nothing about the secondary preferences of Donna and Bob voters. If you are an Alice supporter, who should you be convincing to change their mind? More precisely, what was the process that made these votes be redistributed?

It’s common to explain the proccess in which a winner is chosen with IRV using a Sankey Diagram:

But while Sankey Diagrams are great tools to teach how the voting took place and how IRV works, they still don’t show the current state of voting. In this example, Donna votes are not being counted for any other candidate, yet she cannot win. If Donna is eliminated in an earlier round, or if their supporters move her to a second preference rather than a first, how significantly will the result change? In some cases it could change a lot!

The above “DNA map” shows the full picture of all voters. Looking at it closely, you can infer that while Alice and Bob voters support each other, most Donna’s voters actually prefer Charlie. This could have a drastic effect on the race, but these preferences are not being counted towards the final round. Which means that if Donna + Charlie supporters strategically switch their preferences to be Charlie + Donna voters, then Charlie would jump from last place to the forefront of the next round, eliminating Bob (which was the previous winner!), and eventually winning the overall election.

The previous winner is now eliminated on the second round, the previous last place is now the winner. No voter preference really changed, Bob didn’t lose a single supporter, all from a simple strategic voting change from voters who already supporter Charlie. That this would be possible is absolutely not inferred from looking at the previous Sankey diagram and very hard to see (unless you do some counting in your head) from looking at the diagram above.

An election whose results are surprising, hard to understand and predict and can dramatically change with strategic voting. This is the opposite of what you want in a voting system.

But at least Ranked Choice voting helps eliminate extremism on politics!

Not necessarily. At least not with Instant Runoff. Let’s look at an example. Imagine now a much simpler race with now three candidates: Angry Anne, Brute Bob and Chill Charlie. Angry Anne is mostly angry at Bob’s brutishness and so are her voters. Bob’s voters love him for his “straight talk” and because he stands for everything that Anne supports. Both Bob and Anne’s voters would prefer anyone but their opponents win. Doesn’t matter which country you live in, you probably had a similar situation in your elections recently: two polarizing candidates.

Now imagine that there’s a third candidate. Chill Charlie consistently polls at 20% of the electorate, at last place. But nobody really hates him: Angry Anne voters would like to see anyone but Bob win, and Bob’s voters feel the same. They don’t love Charlie but they see him as a better alternative than the “other side”. Charlie is the kind of moderate candidate that Ranked Choice vote is supposed to benefit. This is how the current preferences are tallied:

How would this election look under Instant Run-off? Not any very different than a two round system. Chill Charlie would be imediatelly eliminated and their votes would be split among the remaining candidates, leading Anne to win.

Notice that if Charlie was in the final round against any of the candidates it would’ve beaten them both. Charlie is the first or second preference of ALL of voters in this scenario, 80% of the electorate would be moderately satisfied to see him win. Yet using IRV he is not the winner and we are left with a scenario in which most people are unhappy that the candidate they hate the most won.

This isn’t a random scenario picked to show specifically this point, but rather a quite typical scene in most democracies in the last few years: two polarizing extremist candidates who don’t have the support of a majority of the population, being rewarded in the electoral system for their extremist views.

So is it over? Should we stop the Ranked Choice voting experiment altogether and go back to whatever systems we had before? Not at all. In my next article I’d like to keep exploring voting systems from a visualization perspective and I want to show how we can have a voting system that takes all preferences in consideration and find the majority opinion while still being understandable and easy to visualize. I’ll explore the many kinds of “Condorcet compliant” voting systems from a designer’s perspective.

He lived the last 30 years of his life under surveillance in a 80km wide, government enforced, exclusion zone, created specifically around him.

This is the true story of the Man in the Hole.

This is not, of course, a story of some super powered dangerous hermit living in a fancy prison. There are terrible crimes, but he was the victim of.

The Man of the Hole was the last survivor or a tribe whose existence we were only made aware after they were all murdered.

In 1986, after multiple reports of genocide of uncontacted tribes, Santos, a representative of the Brazilian "National Indian Foundation" (FUNAI), went to the state of Rondonia to investigate and found a remains of a demolished village, where all the huts had 3m deep holes inside

The farmers accused him of creating a fake tribe to prevent the regional development, threatened his life and he eventually was forced to quit. The story would have been forgotten but 10 years later Santos returned as the head of Uncontacted Tribes section, looking for survivors.

This time he brought journalists and found definitive proof of a lost tribe, which finally got front page news.
Santos kept searching for any survivors and found evidence of a hut with recent occupation, along with tools and some gardens. Someone had survived!

From 1995 to 2006 Santos organized many expeditions to contact the sole survivor of the lost tribe. During one of these one of the expedition members was shot with arrows. After this they ceased any attempt of contact and created an 80km isolation area around him.

But he was surrounded. Farmers kept destroying all the forest around the exclusion area and threatening to kill the Man in the Hole. In 2009 the local Funai outpost was burned and they found evidence of gunshots on his hut. But he survived.

The Man, whose own name we never learned, was found dead in his tent this weekend. He was found in his hammock, with a special ceremonial paint, as if he knew his time was near. Exact cause of death is to be determined but it seems to be from natural causes. He was about 50yo.

After the autopsy, his body is to be returned to his land to be buried.

Along with his name, we will never know what he called his tribe, language they spoke, what they believed about death or whatever burial ceremony they had, nor the purpose of the holes.

His is not an isolated incident. During his (our) lifetime the state of Rondonia has transformed from a wild forest into a huge Cattle and Soy farm.

Both the indigenous people and the officials trying to protect them are under a constant threat of life.

In 2019 Macxiel Santos (no relation), a FUNAI official was murdered in Amazonas, a crime that remain unsolved. Earlier this year another official Bruno Pereira and British Journalist Dom Phillips were also murdered. Arrests were only made after intense international pressure.

Brazil has over over 67 uncontacted Tribes. These are neither a First Contact or Encino Man stories about some unspoiled people ready to see the wonders of modernity. Often these are single families who are aware and going to great lengths to avoid us.

To learn more about the isolated people.

A book on the Man in the Hole.

Corumbiara, a documentary about the case:

If you want more random Brazil Trivia, definitely don't follow me.

Most of my tweets are about random ethereum topics but I will occasionally post random bits on Brazil history.

You can read more about that progress here.

I’d like to talk about the next steps in the improvements we are building.

You can read a more detailed specification of the next features here, but the main two goals are to make commits with payments and bulk commits. The latter is the one that might be more controversial.

Commits With Payments would mean that you would send the ether for paying your domain on the first transaction (commit) and not the second (reveal). This small change, together with referral fees and an optional tip, could mean that the registration app could execute the second transaction.

Meaning the process would change from make one transaction, wait for confirmation, wait another minute, make reveal transaction, wait again into Make one transaction and wait. If you come back in a few minutes and the process hasn’t been finished you could do the reveal yourself and save the tip. This adds the danger that your registry app might frontrun you, but (1) that can happen anyway with the current model as they can simply log your searches and (2) the old process will still be available if you don’t trust your frontend.

Bulk Commits are the more controversial feature that I think would be nice sharing here. This is mostly a gas saving feature: a lot of the cost of transactions is storing data, so this would enable a registry app to make multiple commits into one (magic of merkle trees).

This feature should also allow the bulk registration of lots of new names at once, which can have more controversial effects.

• More efficient registrars: the change of the commit+payment already allows the registration flow to become “user does one transaction then waits”. In this case, the user might not even need to do the first commit transaction, as a registrar app might be built in a way that they await for N names to be requested before doing them all at once in bulk. This could lead to cheaper still registrations (althought it concentrates powers on registrars)

• Club impact: New clubs (10k club, 24h club, Flags clubs) would be easier to register all at once, which might be both good as it allows the quick creation of a club, but it can remove the social and competitive aspect of it.

• Domain squatting: A squatter can bulk commit to thousands or tens of thousands of domains names at once. They are limited by the cost of the reveal, and because we expect that a lot of potentially squattable names have already been done so.

• Frontrun danger: a potential frontrunner bot could register all possible 10 letter combinations in a single merkle tree and then use that to frontrun any reveal transaction they see on the network. This would in practice negate the advantadge of a common commit.

I believe these dangers could be alleviated by limiting the size of the merkle tree and the duration of a commitment to 24h max. This would also make the reveal cheaper as the merkle proof needs less roots to prove.

So what the general community thinks? Are merkle tree based commits a good idea? They could enable massive gas savings and more quick registration of names in bulk, but is that something we want?

Below is a graph of all revenue for the DAO since the beginning of the year. In terms of registrations ENS is having the best week of the past two years, and in fact it’s the second highest revenue (after august 2020). But in 2020 most of the revenue was coming from premium names, in sheer number of registrations, the current trend dwarves everything else by a LOT.

This can be traced back directly to the people behind 10k club. I honestly don’t think if we had paid a million dollars for an ad agency, they could come up with such strategy (in fact, if an ad agency came with me with the idea to get people to register random numbers I would be the first to tell them off!). We could create retroactive grants that would reward people on the club, but this would certainly create political attrition as there would be discussion on the subjective issues of who exactly should be rewarded, who came up with the idea, etc.

An affiliate program is much better. I propose a very standard process:

1. if someone goes into the main ENS dashboard anywhere with an affiliate ENS on their link, the we save the link on permastorage on the client side. We don’t save anything else about the user.

2. If the user clears his memory, the affiliate ENS is deleted. If he arrives again with another affiliate ENS, then that one is overwritten

3. At any point (even if weeks later for a different domain), when someone is about to make a purchase, if they have an ENS affiliate stored, they will be shown something like “10% of this purchase is going to foo.eth”

4. They should be able to click that and we could offer many options: like instead, give it to savethepuppies.eth or cancerresearch.eth or ensdao.eth or some other charities and orgs that we add to the whitelist. Among one of these we could allow them to add a custom ENS name or even an option saying “I’m selfish and don’t want to share the 10%”.

nick.eth:

We’ve discussed this internally in the past. One issue is that if you make the referral program open (anyone can join onchain permissionlessly), someone will set up a “cost plus” registration UI that gives the buyer the referral fee

I see absolutely no issue with that. As outlined above, we could even add that option, transparently, on the UI, to give people a discount, and even shame them with all the good charities they could be giving away to instead. I also suppose that if someone is creating an alternative UI for selling names, they would be much more incentivized to put the affiliate link to themselves (even if it to share it with the customer somehow) and I’m ok with that.

Edit: made a mockup. Clicking on the affiliate link (is there a better name?) would open a popup with a few suggestions of charities or a custom name, which the user could put himself as (or maybe even an option to give it as a discount). I’m ok with raising the prices 11.11% to cover that affiliate fee so if the user doesn’t want it, they can use the old price.

Some NFT holders have asked for us to add some sort of “verified” badge on the avatar, to prove that the image truly belongs to a “verified collection”. I see this as troublesome as it adds centralization end points (the authors of the “verified” collection lists) and it doesn’t fully solve the issue. You can, after all, clone existing NFT and have a “true NFT” that has any image you want. Also, it would requiring having some sort of “non verified” badge for images, which I think takes away from people who just like having their images as their avatars.

I would propose updating the metadata service for ENS with a new layout that includes an ENS name for the NFT collection:

Top left is a simple image avatar, while the others represent NFTs. Notice that some of them are not .eth names.

The underline on the image avatar helps promote the idea that these names are really links, and could even be websites if properly set up. When the image is an NFT the underline becomes a small text. In small sizes the url might be seen as a simple line, but in larger images you should be able to read the URL.

Because the underline is always on image avatars, someone trying to “fake” their verified NFT by just adding the verification overlay on the image, will end up with a striked out URL.

I’ve experimented with some other designs, like having the name be inside the line, or on the side, like a copyright notice, but the underline is my favorite so far.

Notice on how in smaller sizes, a properly designed line just looks like an underline:

To prevent homograph attack, I would add the requirement that the name must all be of the same alphabet. If any mixed character set was found (exception for emojis) then the metadata would display it as if it was just an image.

How do we get the “correct” ens name for a contract?

Of course the whole proposal supposes we have ENS names for major collections of NFTs, many who are already existing and can’t change retroactively to fit a new standard. So here’s how I would propose a standard:

1. Reverse registrar: First, of course, if the address is set on the reverse registrar, then we use that. This is what we already do for EOA but very few contracts have support to arbitrary transactions, and even less have a specific function for the reverse registrar.

2. Allow owner to set it: update the reverse registrar to allow it being set if a contract has a owner() function (and maybe even if that owner has an owner). This serves a large number of contracts (specially multisigs and tokens) and was in the plan anyway.

3. Use DNSSEC on the baseURI() or contractURI() address: these are not part of the erc721 standard but are quite common practice in most NFT collections. Since they need to download the image from somewhere, most are just pointing to an external link. We could use DNSSEC to check if that domain is registered on ENS or if that domain points to an ENS name. This would solve a majority NFT contracts: but there are some exceptions. Namely, some contracts don’t use baseURI, others use it to point to an AWS server they can’t update records to and finally some adopt the (good) practice of using direct IPFS links. For these we’d have to find an alternative solution.

4. Only in the cases that none of these methods worked, then default to a list of addresses → ens names that uses chainlink or kleros as their oracle. This would also be useful for all sorts of other contracts.

This method would not, of course, be limited to NFT verification, but it’s also useful for ERC20 listings or even naming contracts on block explorer and would once again tie ENS to the inner workings of the ecosystem. It’s also a quite decentralized model, in which new collections can verify themselves.

We don’t need to add verification for all collections, but if we can get the top 20 largest ones to do that (or we do it for them) then we could help set that as a standard.

Let’s start at the ENS Registry itself. This is the most important contract, the root of where ownership exists, you can even notice this by the care that was taken in choosing an address with lots of 0s. This makes it harder to spoof and creates tiny gas savings. It’s the contract deployed on all chains including for testing. It’s a very simple contract that uses a nested logic: if you own the root, you can create top level domains, which allows you to create domains, subdomains etc etc etc. You can check who owns the root by going in the contract and asking it for the owner of 0x000..

It should return the root.ens.eth contract, which is just a contract that passes direct orders from its owner–unless the owner specifically forbids that. It has only one locked contract which you can check by passing the keccak256 of “eth”, which will allow to confirm that nobody, not even the root, can change the owner of .eth anymore.

You’ll notice that the owner of .eth is the contract I named “The NFT” because it is the NFT address you add to your wallet. You’ll also notice that the multisig is still the owner of the root contract, per design as requested on EP1. We should expect this to change for the DAO in the future.

Why is the owner of .eth set to the NFT contract and not, let’s say, the dao itself? Great question. If you look at the code in the NFT you’ll see that when you transfer the NFT you are not at all changing the Registry, just the NFT ownership. But the owner can execute the “reclaim()” function which will allow you to set the owner of the NFT to the owner in the ENS registry. So the NFTs in your wallet are not actually the claim on the registry itself, but rather a special token that allows the owner to claim it.

The NFT contract is owned by the wallet.ensdao.eth which is the proper DAO. What can the DAO do to the NFT? It can call the following contracts:

• Change Ownership: this will transfer ownership to someone else

• Revoke Ownership: similar to transferring ownership to a null address

• Set Controller: adds an address as a controller. There can be more than one.

• Remove Controller: revoke controller permissions from the address

• Set Resolver: this is just for setting metadata on the .eth address itself. Not something people usually do.

What are controllers? They are addresses authorized to call these functions:

• Register: sets the new owner of a name that has expired and updates the ens registry

• RegisterOnly: does the same but doesn’t update the registry (cheaper, but user will have to later reclaim it)

• renew: extends the existing period

As you can see, there’s no option that will change the ownership of an address that has an owner. The easiest way to check for this without having to read the whole code is to look for instances of “onlyOwner” and “onlyController”, so you can verify it yourself.

Finally for the governance side. Both the NFT contract, Registrar Controller and token contracts are owned by wallet.ensdao.eth. The only thing the registrarController owner can do is call it to withdraw the money.

The owner of the Token contract has the right to mint up to 2% of the current total supply, once a year. Notice it’s not “per year” but rather it’s an action that, after done, requires waiting another year. Meaning that if the DAO calls to mind 0.5% of new tokens for some usage, that will be the limit that year.

The token contract is then used as the token inside the governor contract, which is part of an elaborate governance contract from Open Zepellin that I haven’t done researching, but suffice to say it’s the thing that counts the votes and creates a 48h delay before they can be executed by the DAO. It’s also interesting to notice that 65% of the token supply, owned both by the DAO and in minor scale, some contributors, is still locked in the time lock contract.

I urge you to verify all these contracts by going yourself on etherscan and checking the code: you don’t need to read everything, but you can start by searching keywords like “owner” to understand what can happen.

So name ownership is quite locked down. Only a owner of a token NFT (or the previous owner until they reclaim it) can change the ENS registry. This is enforced by a locked contract that is the true owner of the ENS root, which itself is under the control of the multisig. Unless there’s some bug in either of those contracts, then no matter how the token holders vote, people cannot lose their domains.

Threat scenarios

One scenario that could be more sensitive is the controller. The DAO can add and remove controllers as will, so while it can’t do anything to existing names, it could stifle or limit the growth of ENS names. Examples that a bad controller could do:

• While it can’t change the expiry date down, a controller could refuse to renew a name for a user for any reason. This would go against the article I of the constitution but right now it’s relatively easy to change that.

• A bad controller could also limit who can acquire new names. It could decide to only accept KYC USD token that required its users to doxx themselves. Or it could require that any new user have a specific token that would identify them as a member of some special club. Or it could straightaway create allow and block lists for who can acquire names. Again, goes against the constitution, but if you have votes to control the wallet, you have votes to change the constitution.

Security suggestions

It’s too soon for us to lock down controllers. There are probably more creative and clever ways to deal with registration than the simple $5 a month, which also requires an oracle and ties itself to the dollar. But we can add more than one controller, and we could transfer ownership of the NFT contract to a locked contract similar to the one at root.ens.eth, which would prevent a few actions or add more delays.

• We could add a last recourse controller that created a fixed price for ENS names at a higher point. This controller could not be removed, not even by the DAO. Maybe it would say that you could always use/burn X amounts of ether or ENS to acquire a year of domain names. It would of course be more expensive than the other avenue, but at least it would guarantee that someone who couldn’t access whatever other restrictions could be put in place. Of course it’s hard to figure out how to price something in this scenario, but that is a contract that is not meant to be used, rather a lever saying “you can’t add restrictions because there’s already a backdoor”.

• Add greater delays on controller changes. Maybe any controller changes should have a minimum delay of 30 days, so that if some change is about to happen that you disagree with, you still have 30 days to add 100 years to your current domains.

That path is neither easy nor without its own conflicts.

Long before Brantly joined ENS, there had been multiple other contributors, many of them queer, at least two were Trans. I only knew that the same way I found out about Brantly’s own deeply held beliefs: casual conversations over dinner in conferences around the world.

As it should be: people’s work only judged by their own merit, independent of the contributors religion, skin tone, gender or country of origin. I think the acceptance of anonymity and respect for privacy in the industry creates an environment where people can be who they want.

I’ve known Brantly for years (he worked with me in Unilogin in 2018) and I’ve seen him do great work. I’ve reached to some of these other contributors and I did not hear a single instance where people felt they were treated differently by him. But he wasn’t just a dev hidden away

Brantly was the de facto spokesperson for the project, the ones that journalists would reach out to hear a word, and maybe the project wouldn’t be where it is today without him. I admired his grit.

It’s hard to be the spokesperson of a community that doesn’t feel spoken by you.

I would like to find a way for Brantly to still be a part of ENS, in a position where he didn’t needed to represent a community that didn’t share his values. Maybe there’s still a space for this, but I feel the rushed termination process might have been too drastic.

This whole debate has raised a much more important question about decentralization and governance. What happens to your names if ENS is taken over by people who don’t share your values? What are the failures of our own governance that led to this?

Brantly was terminated from True Names, as is the right of their directors as a private entity?

But why does a DAO depends so much on a single Singaporean entity?

I believe it should not, and it would benefit for the community to be more legally distributed.

In the beginning of the year I was invited by Brantly to join the core team. It felt wrong then and it feels wronger now:

Going forward I intend that my ENS contributions will be made as a separate entity, with a different jurisdiction, that does not rely on ENS core team.

Secondly: Brantly is still the top delegate. Second is Coinbase, an entity who has a contract for “analytics”with the US homeland security and is, in my opinion, much more problematic than he could ever be.

Most of the other top 10 delegates (including me) could probably be found in the same table at some random devcon a few years ago. Is that a good thing for diversity of opinions and experiences? It can also be very expensive to redelegate, which is not very democratic.

I would like to see a website that helps people redelegate their votes, including some possible form of subsidy (within limits to avoid grieving attacks ofc), to allow a more liquid democracy. I will look into building/financing this.

Thirdly: Brantly is a director of the ENS foundation, a non profit incorporated in the Cayman Islands. I’m sure there are good tax reasons for it to exist, but it also creates another bottleneck for the DAO.

We could have a more public debate on the roles of that entity.

Four: what are the roles of the DAO in .eth names? What can be done to domains if top delegation is taken over by people who don’t share your values?

Not much really. But some could, and we need to investigate and consider alternatives.

The .eth registrar is still under the control of the multisig, but we can expect it to be transferred to the DAO anytime. When it’s done we need to make sure that it maintains it’s locked state and maybe even lock it even more.

As it currently stands, the .eth registrar cannot take away any name that is registered, but it can change the rules on how renewals and new registrations happen. There are good reasons not to freeze that right now but we should try to see how we can limit those further.

One example is the recent rule change for newly expired names, which could be bought by anyone at $2k, has been upgraded to a Dutch auction starting $100k and is being redeveloped as a non linear auction.

The ENS constitution has limits on how these can change, but the constitution can be changed (and it’s still quite easy to do so). Still, some things should be frozen in code so that it supersedes even the constitution changes in the future.

End of thread. So my proposed next steps:

• Decentralize development more so it doesn’t depend on a single person or entity

• Make redelegation more liquid

• Create even stronger property rights guarantees on domain names

Social media is already an integral part of our society, but it’s also ripping us apart. Unfortunately, both the diagnostic on what’s wrong and the solutions on how to fix them are increasingly divided into tribal lines, as are all the other issues that social media debates. Some “solutions” on the table might even worsen the problem by solidifying monopolies and giving them police powers.

This essay proposes to sidestep the issue by separating social media itself — the act of citizens forming communities to share ideas — from social media companies, by allowing a common interoperable standard in which messages generated on one app could be transported and read in any other application, therefore breaking the monopoly on social media publication. Doing so would create a more free and competitive market for companies that allow people access to it, allowing multiple implementations of feed sorting, content filtering, and contextualization.

The Problem

Internet issues should not be seen as a digital problem anymore, rather than the traditional human rights translated to a new online medium. The right to talk to other people online encompasses many rights: free speech, peaceful assembly, freedom of religion, freedom of the press, the right to privacy from their governments, and the right to one’s tradition, language, and culture. Those are all ideals that have long practices as essential pillars in our societies. Now that our world is moving more and more into the digital realm, activism needs to push hard to maintain these freedoms.

On the other hand, these universal rights need to be balanced with newer challenges. How can we combat extremist content without falling into the pitfalls of censorship (either by state or private industries)? How can we contextualize the information we see without empowering companies as the “guardians of truth”? Is a lie always more viral than the truth–or does it depend on the medium?

Falsehood flies, and the Truth comes limping after it — Jonathan Swift

How NOT to fix it

Popular pressure exerted on politicians can lead to new laws that superficially seem to tackle the problem and create more profound issues. A good example is legislation that requires social media companies to use filtering algorithms to identify and root out terrorist content, graphic violence, and copyright infringement. Politicians tend to propose goal-oriented laws because it allows them to show their constituency they are fighting specific issues that are important to their electors (“Facebook has a problem with A, so we will pass a new law forcing them to do B”). These new laws can create second-order effects that can make the problem much worse:

It creates slippery slopes: the definitions of pornography, violent content and hate speech are subjective and can vary across jurisdictions and cultures. Even restrictions that seem straightforward, like “no nudity”, are more challenging in practice. Facebook learned this early on when nursing and breastmilk advocacy groups complained that breastfeeding photos were being removed as “porn.” They started fine-tuning the rules but found more and more edge cases, like “adult erotic breastfeeding” (porn) and “human-animal breastfeeding” (a non-erotic cultural practice in some drought-affected rural areas). How can you create a rule for “no underage nudity” that doesn’t accidentally also block historically significant war photos or photos of Yanomami children playing? It’s a fool’s errand to try to develop a universal set of machine enforceable rules for all contexts.

It creates collateral damage: even the most atrocious content is necessary to be kept in some contexts. For instance, when youtube deleted ISIS propaganda videos, it also unwittingly deleted war crime evidence needed to prosecute captured ISIS fighters. While the government was trying to cover a spike in Mexico’s cartel crimes, citizen journalists started sharing execution videos as proof of the contrary. Suppose someone in power is saying something that can be considered hate speech. Should the content be deleted to avoid further harm or kept as a public and historic service?

It deputizes private companies as extensions of law enforcement: when your video is taken off youtube for copyright violation (even if it’s your work or performance of a public domain song), your only recourses are youtube’s own “court system”, an opaque system that is not held accountable by anyone other than Google management, meaning that for most people, especially non-American citizens, if you are unfairly accused of something, you have very little recourse. It might feel entirely inconsequential while we are merely talking about simple music performance. Still, like everything else in society, as more of our lives become digital, it’s unavoidable these private courts will take on bigger and bigger responsibilities. Newer legislation that forces social media companies to combat terrorist content (however that is defined) will inevitably make the tech giants an extension of law enforcement. This symbiotic relationship usually goes both ways. As governments ask private companies to surveil their users to enforce specific laws, these tools typically make their way back to the state surveillance mechanism.

It creates a barrier of entry for new startup and enshrines monopolies. Suppose all websites that hold user content must hire many moderators or train a complex AI filter. In that case, it creates a minimal floor that sets how small a new social app can be. The more stringent the rules for social media companies are, the harder it is to innovate and create new apps that will dethrone the big tech giants. In our lives, we often accept tech giants’ inevitability, but this flies on the face of their own (relatively short) history. Facebook and Google didn’t exist 20 years ago. They reached success by launching a slightly better version of something that already existed before (Myspace, Altavista, etc.). But regulation that puts too much of a heavy burden on smaller companies might make sure they are never dethroned.

The Right to Speech vs Right to Reach

The right of a private business to ban from their platforms certain types of speech or people is predicated by the fact that they’re not a government agency and that these people still have a right to speak in other platforms they create themselves. But if the walls between governments and private corporations are becoming more blurry, and monopolies threaten to remove any sort of other option of public spaces.

In short: Twitter should have a right to stop a given politician from posting in their website, but not from shouting outside their own window or a street corner.

Social media posts are a natural evolution of websites and blogs, a slow 20 year tale in which these tools have become easier to use and have reached more people. In the late 90’s having a website meant building everything on your own. By mid 2000’s this was simplified in Blogs by making it easier to post updates to your own website, which could be read by any application that supported RSS. But by mid 2010, most social media apps were all in one: you downloaded a single app that would allow you to read other posts, and write to the application website.

We gained users, but lost control over our own content.

Wait, don’t we have social media interoperability already?

Tom Eastman on Twitter: "I'm old enough to remember when the Internet wasn't a group of five websites, each consisting of screenshots of text from the other four. / Twitter"

I'm old enough to remember when the Internet wasn't a group of five websites, each consisting of screenshots of text from the other four.

No. There are many ways in which social media posts can break the limits of their walled gardens. There are official methods, like media embeds or user-generated approaches, usually screen grabs or copy-pasting the contents from one to the other. Both have their particular problems, but the sheer amount of content from one social media site found on another via either method is an excellent proof of how much demand there is from the users for such capability.

The problem with the first approach is that it depends heavily on what the provider wants to do with it. If a politician posts something that years later they feel might embarrass them, they can delete it, and this will remove the content from every site that embedded it. On the other hand, when things are posted via screenshots or simply pasted, any authenticity is stripped away. Is that a fake parody quote, or did that person say this? Is this quote from someone else being now misattributed to another person for a more viral impact?

Reframing the problem

We started talking about hate speech and the future of online democracy, so the “chain of custody of social media posts” seems a relatively innocuous and trivial issue. But bear with me as we rephrase the problem. You’ll see how such a small technicality can have huge implications on the future of online speech (and, therefore, all speech). The issue at hand is:

How can we allow multiple parties to archive social media posts while guaranteeing its authenticity?

Once we reframe the question like this, it becomes evident that there is a solution that you have been using in your life for many, many years: cryptographically signing messages. Before installing a new software update, how does your device verifies that there was not an issue downloading it? Your phone comes out of the factory with some known hardcoded keys. Before doing any updates, it checks the new software’s signature against the ones it knows from the software makers. When you go to a website, and it shows it’s a “secure connection,”? It checks the content’s signatures to the keys of known internet providers, IP hosts, and significant content publishers. It’s also used in many mission-critical financial transactions, both in banks and cryptocurrencies. When a bitcoin node operator receives an order to move a million dollars from one account to another, it doesn’t care how that request arrived at them, how many people handled it, or which software version generated it: all it needs to do is verify that the signature of the message checks with the known, public key of the account that holds the funds. In fact, in the cryptocurrency world, it’s the only thing it needs to know about that account!

Cryptographically verified messages: the new RSS

So how exactly would the future of social media be? Not that very different from the past. Similar to the RSS protocol, every social media site would publish a file with the content of the latest posts by that user. But it would have some significant differences:

1. Beyond the usual metadata associated with it, it would also come with two extra fields: a cryptographic signature of these posts and the public keys that signed it

2. Publishers would also make available the history of all public keys associated with every account and periodically rss it as new ones were added and old ones revoked

3. These messages would not be only hosted on a single file on the publisher’s site but also posted to an open distributed network in which anyone could set up new listeners or publishers

Let’s unpack that.

An associated signature with each media post: this would guarantee authenticity with each message. More importantly, it would allow you to separate how you received the message from its veracity. These social posts can travel via multiple websites, email, forwarded by messaging apps — you would not need to go to a third party to check its authenticity. Of course, it doesn’t judge the veracity of what is being said, just that you can verify who said directly from your device without having to check a third party. More than “you don’t need to check twitter to see if it was posted there,” but “it doesn’t even matter IF it came from twitter or Facebook, you know it came from this person”.

This exists already elsewhere: when you send a transaction in Bitcoin or Ethereum, there are popular sites in which you can, given a hash, check information about it. But those sites are not the sources of information, just a popular archive of it. If one of them goes away or deletes the data, you can check the same authenticity elsewhere.

Publishers would also periodically publish a list of active and revoked keys from accounts. Social media publishers’ critical role would still be to verify the account itself and link it to any meatspace persona. These publishers shouldn’t hold all these keys but would have a standard process of verification that a key belonged to a user, using passwords, emails, or other methods–just like they already do when authenticating a user on their website. The process of authenticating a new key should be open to any app and would only tie a public key to an account on that website, not necessarily outside of it. This isn’t a process of verifying if that account has a government ID or if they control the brand rights to the name they are using (but websites could offer these services). It’s also cross-compatible, so you could use the same device key to validate your account on both Facebook, Twitter, and YouTube. Validation can be in the form of the most basic “The user BobWY1997 has these three keys currently associate with him” or “We verified that these keys belong to the same owner associated with the email jennytut@gmail.com and the number +(201) 867–5309” to a more advanced “this is the official account for the White House spokespersons”. These lists would be publicized and updated periodically: some keys could be revoked and updated as their users changed their devices or new presidents were elected.

Messages would be published to an open, permissionless network: while RSS provided a convenient way to get the contents posted to a blog, you still needed to host your feed, meaning that if your site went down, so would the content. In this scenario, all messages would be relayed through one (or more than one) network that would rebroadcast some messages to their peers, similar to email servers. Not all nodes need to be equal or have any obligation to carry, archive and rebroadcast any message they are not interested in, which could open some opportunities for niche services for a geographical area or a given interest.

Is that this blockchain stuff again?

No! While P2P networks and signed transactions are wildly used (and necessary) for cryptocurrencies and other blockchain-based technology, blockchains themselves are not needed for this use case. Blockchain is a technology whose primary goal is to find a global consensus on messages’ exact timing. If both messages A and B are broadcasted within a few milliseconds of each other on different sides of the world, each witness in the network might receive them in different orders. While this difference can mean who gets some extra millions of dollars in some machine run financial applications, it’s mostly irrelevant for most cases when we are talking about media supposed to be consumed by humans. There are some edge cases in which a user might want to tie their message to a blockchain (to prove they have posted a message on a given date), but for the most part, this proposal uses cryptography but not much on cryptocurrency.

How would that fix things?

It won’t fix everything, but it can make a big difference in how competition works. In practice, this would make social media an internet primitive, a shared public good that is not owned by any single company. It would also allow a vibrant, competitive market for social media app makers.

Disinformation and Fake news: a single app would not control how to display and filter your feed, meaning that any enterprising developer could build their filters to spot unauthentic content and prevent the spread of misinformation.

Advertisement abuse: With the ad market’s fragmentation, no single company could then abuse ads to target minorities or spread misinformation. If you don’t like the type of ads you see or feel your feed is being used to influence your habits, just download another client. Your friends and content will be able to port over!

Bias in media: On the other hand, this also means that if you fear that your app is biased towards a political cause you disagree with or is unfairly editing or even censoring some voices you support, switch your app!

State censorship: This would also make State censorship much harder since even if they block some specific apps, a user can use an unofficial app to get to the same content.

Beyond Social media

These examples are all about social media, our current usage of twitter, Facebook, etc., but the technology could expand to many other internet areas.

Portable user reviews: many things make a few marketplaces an almost monopoly, but one of these locking methods is indeed products reviewed by the user. If you are an Amazon reseller feeling like amazon is eating your profits, you can use other places to sell your stuff, but you will lose all your user ratings and reviews. If these are all made in a compatible, portable, signed hashes, a seller could take their reputation with them whenever they go, encouraging better marketplaces.

Instant news articles: one severely underestimated factor in the dissemination of false information is the fact that when an item is shared in a messaging or social media app, the article headline and main image loads right in the client, no action necessary. If someone wants to read the content to check more details or context, the site will often take a long time to resolve (usually due to a series of user tracking third party code), be closed in a paywall, or provide very little extra content. This makes clickbait headlines go viral, even if the article’s content is not that enraging or absurd. If whole pieces were packed in signed bundles, they would load as fast as downloading an image while retaining a validity check written by an entity you trust.

Wouldn’t that make banning hate groups impossible?

The dark side of the coin that makes it impossible for the Chinese government to censor conversations among Uyghurs or for Russia to ban groups that promote LGBT rights is that it would also make it harder for western governments to combat groups that disseminate neo-nazi propaganda, racist, genocidal ideas, and other hate speech. But an argument can be made that the real issue with our current society is not that these ideas are new or they didn’t exist before: but that they are now mainstream.

Before the internet, you could always print your letter supporting scientific racism or promoting your local cross-burning KKK group–but you would never get that letter published on the NYT or on TV (unless you threatened to bomb people via the post). Even before social media, sites that promoted despicable ideas would often find a hard time finding some providers to host them as soon as they got enough attention.

But when a half dozen websites host a billion people’s content, hate groups can not only flourish; they can also use the own internal marketing features to promote their groups to other like-minded antisemite conspiracy fans. Youtube and Facebook have been called a radicalization machine, and their defense is that they have too much content to moderate it all.

If they are too big to moderate their content, then maybe they are too big to exist. In a world where social media content is interoperable and can be posted across networks, any app is free to use their filters to decide what goes in and what goes out, what is acceptable or not. If a significant company finds your content unacceptable, you can always move to a smaller, niche platform. If you are banned from even those smaller niche, you can host the content and handle distribution yourself. If you can’t do it, then maybe your ideas deserve to be forgotten. Like in a working free society, harmful thoughts are not mandated away; instead, they slowly die out, as individuals force them off of the main streets and back in the gutter where they can be collected by researchers working on vaccines that require gut bacteria samples.

Nice idea, but how do you expect it to happen?

Don’t underestimate the power of the web to change itself. It has been doing it nonstop for many years. This goal can be achieved in many complementary ways, either by voluntary cooperation, adversarial interoperability, or governmental mandate.

Voluntary cooperation: Of course, Facebook has no reason to voluntarily breaking itself up and allow the most valuable part of its business, the social graph, to be taken by anyone who wants it. But while Facebook is the biggest, there are many competitors, and more are popping up every day. If Twitter and a few other smaller sites voluntarily supported such standards, they could benefit from a range of newer clients developed by third parties, which could force the rest of the market to adopt it.

Adversarial interoperability: not all standards emerge from cooperation. During the browser wars, some browser vendors often would reverse engineer innovations created in Internet Explorer meant to lock users in and make them available in their platform. Open Office spent a large amount of energy trying to correctly read a closed source office document and make sure it was the most compatible tool. These are two examples in which a monopolistic power (Microsoft) ended up ceding and adopting an open standard.

Government mandate: there are many proposals to regulate social media. As discussed previously, many of these might make the problem worse by creating such a burden of requirements to host user-generated content that only big players can do. But suppose there is an emerging standard of compatibility for social media that can break the current monopolies. In that case, governments worldwide can point to that and say, “you should follow some industry-standard. Otherwise, you’ll force us to create our own”.

Communities that last centuries

Today, you can still walk on roads that have been laid thousands of years ago. But you can also visit places that have existed for a long time but were suddenly dismantled in a short period. Communities were people were born, lived, fell in love, that disappeared due to a single decision from a board somewhere or a sudden market movement.

The difference between a structure that can last centuries is either the people who live in that community can maintain, repair, clean, own it—long after the people that built it originally are gone.

Our digital communities are where relationships are created, fights are fought, ideas are debated, new births are announced, deaths are mourned. And yet, they can all be deleted or disappear in an instant, with the unplugging of a server.

We can build digital communities so they outlast their builders. So we must.

Ok, this is an exaggeration, a composite of many nasty popups, tabs, and other anti-patterns I found while navigating. Here are two real-world examples, the apps Zapper.fi and Zerion. I want to highlight not the apps’ content, mostly, but the many bars on top and the bottom of the screen. Notice how on the left side, the top bar for Zerion has two similar “x” in a similar place, followed by a hamburger menu.

But the worst offender in this list is undoubtedly the triple bottom bar in the zapper.fi app. The bottom two are from Status, and the top one is from Zapper. Who designed this? Well, most likely, no one did. The old saying, “success has many parents; failure is an orphan” applies very often to design. Design failures are not usually planned, but a set of decisions that individually are not wrong but collectively become a bad idea. Zerion having a top bar suggesting you download the mobile version followed by a hamburger menu is standard practice. Zapper using a bottom bar is a good idea in its face. Status having two bottom bars always visible is… Well, no, this is a bad idea.

Why is bottom navigation bars so typical in mobile, while the same navigation often becomes a side or top menu on a desktop? The reason is quite simple: it’s the natural area in which our thumbs can easily navigate around when you hold the device one-handed. Also, because your thumb is an imprecise instrument, they’re on the bottom so that if you hit them slightly below or above them, then that’s still ok. Similarly, the top menu or all the screen sides are used on desktops because if you move the mouse cursor quickly, that’s the longest and most comfortable hit area. Suppose you configure your computer so that a second monitor is arranged above the main desktop. In that case, you’ll see how much of a burden it is to hit the menu or bottom bars on the Mac–instead of being just a quick swipe of the cursor, now you need to hit precisely the border between displays. Creating two (or three in this case!) bottom menu bars transforms the area from a lazy reach from your thumb into a complex control panel.

The reason that Status had a double row of bottom navigation seems to indicate that the main navigation and the “browser” navigation were built designed separately, with both adopting the bottom bar as the “natural” way to navigate that particular hierarchy. So it’s natural to expect that an app designer, also working from a different blank slate, would also want to use this prime spot — and therefore, we end up with the haunted triple bar. Probably not designed by any individual, still what the end-user sees. It’s also indicative of a misunderstanding of the hierarchy of functionality versus the hierarchy of usage. From a company perspective, maybe developing the wallet or critical management took a lot more resources than the browser — browser is just one feature of many. But all features follow a Pareto rule: there’s a tiny number of features that account for 80% of usage, and that’s where the browser is.

What is the purpose of these buttons? I arranged them in this diagram with a color code:

We have two different buttons that will take you to chat rooms (although in other areas) positioned on different sides of the screen. Similarly, we have two buttons that will often take you to the same place, the “home” of the browser bar, one on the top another on the bottom. Going “home” on the browser bar has an unhelpful “×,” which makes it seem you are “closing” something. On Safari, the “×” is used briefly as a symbol of “stop loading,” It’s also used as a symbol to delete the URL and write a new one. This particular “×” does neither. I found it quite hard to type a new address since you need to tap the address bar multiple times until it selects the full address and then types backspace on the virtual keyboard. In the example I’ve shown earlier, a similar “×” is used to close a top informational bar. The top right corner is quite a noble position for such an unremarkable and imprecise button.

For the 12 buttons visible on the screen, what would the user probably use the most? Of course, this would require user testing, but I would be willing to bet they would be, in order, the navigation, followed by identity, followed by chat, and finally all the rest. Using that rule, we could probably hide most of the other buttons. A lot of the navigation can be done via gestures that are already standard in iOS, swipe from the left to go back, to the right to go forward, slide everything down to close the tab. Of course, these should be offered as additional, a back button icon should be present.

The four buttons on the bottom bar represent an identity crisis in Status: what is it, a messaging app, a dapp browser, a wallet, or an account management tool for your crypto? Of course, that decision needs to be a strategic one from the team, but I would dare make a bold suggestion here: drop the wallet.

A wallet is just an app among many that you can use. Many wallet interfaces are available on the status “app store” that offer pretty much the same functionality. Don’t remove that functionality, of course; just put it in the same level as any other “favorite app” as a removable default. The second suggestion would be to hide the whole account management thing deep in some hierarchical level. A user will rarely need to use it to get back some of that real estate space back. What’s left is a browser and chat, which reveals what status should strive to be:

Status is a social app browser for crypto

It’s the easiest way to interact with crypto apps, but it’s also something you can do while interacting with friends. A universal discord chatroom for all Ethereum. Let’s look at the same page, but remove all the disabled and redundant buttons and hide some of them inside the new icon representing where × used to be.

It’s clear that there’s enough room for us to not need a double bar anymore. But I think a cleaner state like this is an opportunity to think about the app’s meaning and depth. We could have a bottom bar with just three buttons–but navigation buttons only make sense inside a browser window, and you can think of a chat as something on top of all apps, a toggle of sorts.

In this design, Status starts as the main app offering all the cool, exciting stuff Ethereum has to offer and then gradually disappears in the background until the app uses all the space on the screen. Notice even the bottom bar navigation has only two buttons, but these two can also become invisible. These buttons will reappear once the user scrolls up (a standard practice in many apps, including Safari, Google, Preview, etc.). Still, most of the same functionality can be achieved by gestures: swipe from the left to navigate back, scroll down to make the top bar appear, and finally exit the app completely.

Swipe from the right could even be used to show the chat page, again reinforcing the concept of Status as a shared social browser. Or maybe it could even be on the back of each tab, with a flip around animation.

In Conclusion:

Designers don’t always control all the experience, and sometimes that’s good. Also, an issue with UX is often an issue with a fundamental division, from within the team on what they’re building. Often we want to show on the navigation all the effort we put into making our features, but the reality is that a few features will account for most of what your users will use. Hide the other 80%, and you will get a lot of new blank space to play. Use that to rethink the hierarchy and depth, and you might come out with a brand unique experience from just moving stuff around.

Response from Status

Before publishing this post, I’ve sent the draft for the Status team to take a look and they provided me with a response, quoted below:

Introspecting, when focusing a on Browser, a challenge that absorbed our attention has been how to provide access to dapps, while being at the mercy of Play/App store policies. Hence the spin-off https://dap.ps/.

Regarding gestures: (…) We have a long standing issue for the browser address and tool/nav bar to ‘hide on scroll’. This is definitely a good reminder to get back to that. (…) Gesture interactions can pose it’s own challenges of staggered interactions, less visible but similar to the multiple tab bars or close items. E.g. horizontal scroll in the dapp, in the browser, between tabs.

The potential of moving ‘key management’ to the background is definitely there. At the same time, there’s power in considering ‘wallet’ (i.e. account management) an integrated component. For example, to facilitate sending funds over chat, register an ENS username for use in chat, moderating chats through staking mechanisms, setting up paywalls to provide services, or block unsollicitate connections, voting in chat. These types of features benefit from direct access to the associated accounts.

Generally, you’re touching on a critical topic for us with the suggestion to move wallet, as we need to deeply understand the distinction between key management, identity and wallet interactions for purpose of transactions. Food for thought for sure. Here’s a prototype of a more Browser centric (or OS -like) navigation you might enjoy:

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F8UfZlEllSrM%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D8UfZlEllSrM&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F8UfZlEllSrM%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

Thanks Simona and the rest of the team for the reply and the hard work you’ve put in Status!

Not necessarily out of money, but the current Ethereum gas market, the rise of DeFi, and new browser standards have changed the game significantly enough that we don’t see a way forward with the project.

UniLogin started two years ago with a vision for a Universal Login standard for Ethereum, a way to onboard new users to Ethereum directly from the browser, using smart accounts and abstracting away all the gas. While the idea was very well received by the community (we packed the second largest stage at Devcon 2018), we made some bets on a few assumptions that turned out to be untrue.

Incorrect Assumption #1: Browsers could be counted to store low value secrets

A big part of the magic behind “create any account without downloading or installing anything else” was that we were using localstorage for initial secrets.

We knew localstorage had a lot of issues: a malicious browser extension can access all your browser info, a DNS attack could be used to phish users, etc. Our strategy for that was to push users towards multisigs: every time you logged in from a different browser or device we would add another key, meaning that if one of them was stolen, the others could be used to prevent or limit any harm. We could even add further security by making stronger requirements for larger amounts (e.g., to move anything over $20 you need to install a phone based app).

But we didn’t expect to be caught in a fight between Internet giants. Localstorage, cookies, and any sort of client side memory is widely used and abused by marketers to track users across the web. Some browser vendors (most prominently Apple) are fighting back by being more aggressive on their memory wiping policy, including erasing all memory if the user doesn’t visit a site in 7 days. As a result we (and ironically, a lot of privacy preserving “burner wallet” websites) simply can’t rely on that method anymore.

As a result, we had to change our roadmap to include signing in via email. We thought it would be the least invasive of the authentication methods (e.g., compared to social media sign in) but it did mean that now we would be hosting (client-side encrypted!) our users wallets. It also significantly altered our flow, since we wanted the only identifying information for the user to provide to be an ENS name.

Incorrect Assumption #2: Scalability wouldn’t be a problem

This was an explicit assumption in our presentations: usability was more important than scalability, and given that there were so many deployed L2 solutions on the market (like xDai), as soon as scalability became a problem we would all move there.

This turned out a deadly assumption: as soon as we had our email sign-in solution ready, gas fees on Ethereum made the whole process unworkable.

UniLogin is particularly sensitive to gas prices because before onboarding any users we were deploying on their behalf a new multisig wallet, registering an ENS name, and sometimes using our relayer to add a Dai transaction. After that, every new sign-in on a different device required a new on-chain transaction (to add a new key) and every transaction would be a bit more expensive due to the relayer. Some days the whole process of onboarding a new user was costing over $130! Meaning you could buy a hardware wallet for the price of signing up on our app.

We don’t consider this to be a temporary problem. Even if the gas situation improves and makes the cost of user onboarding 10x or even 100x better that would still be a deal breaker for many mainstream applications with millions of users.

Incorrect Assumption #3: Ethereum is meant for everybody

I still hold this belief and hope it will be true again in the future, but at the moment Ethereum has been going through a process of gentrification, where big defi users are pricing out all other usage of the network. Games, NFTs, DAOs, and many other exciting use cases are simply inaccessible at the cost of multiple dollars per transaction. Of course, the natural course will be that a lot of new stuff will move to L2 or their own chains, but right now at the moment the process is scattered, where many apps are using different scalability solutions.

The result is that it’s quite hard for someone to build a system right now as the One Universal Account. For the foreseeable future (which is very short in crypto!) I expect that a lot of interesting use cases will migrate to xDAI, and that some stark/rollup solution will be the basis of a trading-specific chain.

Conclusion

Because our team is small and lean, we could easily squeeze out another six months of product development and maybe try to find a bridge investment (you can add a #4 to a list of incorrect assumptions: “that a global pandemic and recession wouldn’t dry up a lot of VC capital in early stage startups”).

One more direction we considered would be to do a full pivot into a L2 defi focused wallet or a sign-in solution only for a smaller set of products in xDAI. However, this would be almost a restart of the project and so we decided simply to return the remaining cash to investors and then go on the next opportunity.

The wallet market was very hot two years ago, and now that yield farming is the new hot thing, wallets are going through a natural consolidation. Portis is now ShapeShift. Fortmatic is now Magic and is focused on passwordless signups. Argent (which I consider to be the closest implementation of the original vision I had for Universal Logins) announced their login SDK at EDCON 2020, but haven’t deployed it yet. Also a shoutout to our friends at Authereum which are still working hard on figuring this gas thing out!

Because we always used the open philosophy of putting users in charge, we can’t actually shut off access to user wallets, because they are actually just a standard gnosis safe. We will continue running relayers at least until the end of the year to facilitate users migrating their interfaces and funds elsewhere. If after that you still need some help feel free to contact marek@ethworks.io and we will help you figure out what you need.

Whats next?

My co-founder Marek, along with the rest of the team, will be joining the ranks of Ethworks — setting out on a journey to become one of the top Ethereum and blockchain service companies worldwide.

For me personally it was quite an adventure. I travelled to many places, met a lot of great, lovely, beautiful, intelligent, inspiring people, stepped out of my comfort zone, had great conversations with VCs, founders, and builders of all walks of life and did things I had never done before. I’m thankful of everyone who I met in this road and hope to see you soon on whatever my next step is.

So long and thanks for all the fish.

Out of Gas: We’re Shutting Down UniLogin was originally published in UniLogin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mist was a brainchild of Gavin and Jeff but I took the lead of it when I joined the foundation in 2014. We had grand plans for it being the realization of all web3 technologies we were building and it was planned as the main software release of Metropolis

However the first 2 years I worked on Ethereum we were mostly focused on the Wallet app, so it started being released as a beta in 2016 and we started a security audit at the same time. The Foundation contacted Mario Heiderich from Cure53.

It was a great piece of humble pie.

As a designer I had spent a lot of time working on small things that I was really proud of, for instance instead of the URL being a simple text field we wanted to show all the url elements in a proper hierarchical order. But turns out Meteor’s SafeString wasn’t that safe.

We would then build our own sanitizers and then they would come back to us with “actually, this isn’t enough, there’s a bug in Webkit using this particular character so we were able to execute javascript code by encoding it in a token’s name”

A lot of the exploits were abusing long strings to hide information that could be used to phish the user, or things that didn’t even cross our minds, like “we can actually make a draggable object from your site overtake elements from the UI”. We were impressed.

‹1 / 2›

At this point everything was fixable. But at some point they started going deeper into our tech stack: you could force an error in Node.js to reveal information about the user’s folder names. You could abuse our injected provider and override the native JSON parser functions.

And then the really scary things started popping: the found out how to abuse electron to access privileged commands not even Mist should have access to. At some point a POC was able execute any app in the computer. This is scary for a normal app, but fatal for a crypto wallet.

The whole process took over a year of back and forth, where they would find issues, we would fix and come back to them. At some point issues started escalating to Electron team, Chromium and Webkit. Cure53 itself said it was out of our hands and they couldn’t have predicted it.

‹1 / 3›

This was fundamentally the end of the project. We explored different approaches, using other frameworks, building our own, starting from scratch on a completely different language. We saw Brave pop up and eventually abandon Electron too. In a year Mist would be discontinued.

I wouldn’t have thought about the report again, if it wasn’t for @Jordancoin pinging me about it, wanting to learn more what we learned ourselves and it made me realize these lessons could be applied to more people building desktop wallets in crypto.

So I’m sharing it now.

I hope this is useful for some people. Thanks Jordan for pinging me about it, @Silverhair72 for digging it out again and of course my former team mates @feindura , @evertonfraga , @mhswende, @MaiaVictr, @Philipplgh, @wolovim for working so hard to dig us out.

While I’ve been an ethereum evangelist for the past 6 years (it feels so weird to type this!) I have never tried selling people on the idea of buying any coin., because while I am a believer (and hodler) of many assets, and an avid user of DEFI in general, I’ve been always more excited about other non-financial promises of blockchain general computing. Among them, blockchain games, to the extent I said this back when “games” in ethereum were either casinos or cryptokitties:

What I want from blockchain games:1) be a good game first2) explore what makes blockchain unique3) design around the limitations4) persistent always on world 5) players own the game, the items and experiences6) allow anyone to design and improve the game7) embrace bots

A new game I’ve been testing out (a bit excessively) last week, Dark Forest, hits almost all of these except for a few points that they could very well explore better when it’s moved from a testnet into a layer 2 like xdai (owning NFTs, universe persistency, bots). And it has the very interesting twist that uses ZK-Snarks for creating a hidden information game.

It’s a space exploration game with no graphics: a classic formula of exploring the universe to find unconquered planets, and then using the resources from these planets to explore and conquer more planets. The game map is derived from computing a hash of coordinates, which means that the universe is pre-determined the moment a salt is decided, but can only be found by computing all these hashes, so exploring is a sort of proof of work. You then move from planet to planet not by publishing the coordinates in which you’re moving, but rather you submit proof to the chain that you are doing a valid move, using zksnarks circuits. But most importantly for the purposes of this article: it has terrible user interface.

A great compelling idea of a software, with very complex technical concepts that need to be explained to the end user, with a terribly confusing user interface designed by engineers? That’s the sweet spot for a UX designer like me. So let’s go and explore not only how to improve it, but how my process works so that maybe you can apply for your own software.

#1 the difference between the “theme” and the “experience”

A theme is how the game purposefully looks. Terms like “ugly”, “retro”, “pixelated”, “text heavy” relate to the theme and are all valid options. Often when developers (and inexperienced designers) talk about making a better “interface” they’re talking about having nicer fonts, 3d buttons, shadows, colors, etc.

The Theme (aka a “style” or called a “skin”, when it can be changed by the user) is an artistic decision. Your game can decide to look like an old school BBS or a bubbly display from the future. While of course those decisions have technical reasons behind often (it’s easier to create pixelated sprites, or make changes on a text heavy interface when you don’t have a designer on staff) they are still stylistic options. Things that you can even set for a user preference are usually themes. But if you are discussing “this can be done with a less clicks” or “the user is confused by this” then we are in the realm of user experience.

I find the latter much more interesting, because often you can offer solutions that are even less work to implement, but can drastically improve 10x your user acquisition. Also, a developer might feel they are not capable of “designing” a new theme, but they can always be empowered to learn to optimize the experience like one would optimize an algorithm.

#2 If you need to explain it, then you’ve failed already

The first experience is fundamental for any software development and is often renegated by developers because it’s the screen they never see, full of empty and unselected stuff. This is the first screen a user would see when they log in the game:

You have a terminal on the right, a lot of information about planets and fleets. You have a popup with crucial information on how to play, but the user will probably close it out before it reads it because at this point it’s suffering from information overload and wants to go to the game already. They probably don’t know at this moment but this is the most important piece of UI they should look at first:

Unlike many panels this one has no lore, no explanation, no story and set of minimal and confusing buttons. Yet this should be the first thing the user needs to learn about. “Mining” is a bad metaphor for explaining Proof of Work crypto currencies and it’s even worst for a game, even if it’s technically correct. It gets worse because the player will find planets with the “silver” resource which grows over time but is completely unrelated to this mining panel! In this case you are using your computer CPU to explore the map and find planets, so we can simply call it “explore”.

Notice that I did not change the “hacker style” of the game, kept the black and white and text heavy, because our focus is UX, not changing the theme. That should be a separate effort. Sometimes “redesigning” can be as simple as calling stuff other names.

I renamed the panel to “explorer” and created an icon for it. I chose an spiral inspired by the idea of a Sophon, a particle-sized computer that is invisible but is used to gather information on the Dark Forest book (I would not use the actual name, because while this game is inspired by the Liu Cixin trilogy, it’s not meant as an official license of the IP). The icon itself doesn’t matter, but it’s important to show another copy of the same icon on the map, showing it moving around as it explores the unknown region of the map. In the first phases of the game the most important thing the user should do is move the explorer around and drag the map so they can understand what they’re doing. In fact, since most of the panes in the UI were empty or context dependent, the whole first UI could be reduced to this:

The User doesn’t need to be explained the UI because the UI has very few buttons on it. He can can move the explorer and drag the map around to find new planets. Once he finds them we can have more panels appearing with the context. Now where did the rest of the interface go?

#3 Kondorize your room

Sometimes you don’t need a designer, you need Marie Kondo: often a lot of great work can be accomplished by looking at all your elements with a fresh eye and asking yourself where they belong, and what goes with them. And if they don’t bring you joy, get rid of them. Often a common mistake is that developers start by making menus and then filling them up, before realizing if they actually need that particular piece of UI. Now let’s look back at our previous UI and understand better what it relates to.

Related information is all over the place. Some important panes use very little space, while some completelly useless ones (“planet lore”, a randomly generated description of planets, or a “landscape” view) uses a large amount of space. Panels that are very similar in nature: upgrading a planet or managing your fleet are far apart.

At least 20% of the screen is taken by a log window. While this is probably important for developers and sometimes even for the players (if their transactions fail, for instance) it’s inneficient use of space. For developers it should have a toggle visibility hidden somewhere so that most users don’t see it, and any important warnings meant for end users could be put in a temporary notification hover in the top right. Global properties like your score, or a list of top found planets are rarely needed and could very well be hidden inside one click. Another terrible usage is the toolbar which basically has information replicated elsewhere:

This toolbar contains help, some links to panes that are open elsewhere (top planets, upgrade, manage), a link to a pane not found elsewhere (top players) a link to connect to your twitter (which could be inside your profile) and another for broadcasting coordinates to a planet. While this last one has some questionable strategic reasons and is very aligned with the lore (without getting into book spoilers but the dangers of broadcasting the location of a planet with intelligent life is the driving force in most of the Liu Cixin trilogy), this option really just creates a tweet with the numerical coordinates and could be moved inside some other pane.

Often when designing a UI developers first decide on the navigation and then decide what goes in there. This is a common error and often leads to a navigation that is unnecessary, specially when they start adding buttons for “coming soon” features.

Now that we looked at our closet drawer, what happens when we separate all the socks, shirts and pants in their respective places?

All contextual information (including “broadcast” option) only appears on the right when a planet is selected. All other global information appears on the right when the “menu” button is selected. Other options, like showing the console, could be hidden in there too. This allows most of the interface to be hidden only when the player needs to look at it.

The main lesson here is: figure what stuff you actually need to show user, and when. Group stuff together, hide stuff you use very rarely, throw away stuff you never use. It works for your closet as well as your UI.

#4 Discoverability: Less is not always more

Finally let’s talk a bit about the proposed contextual menu:

As an exercise, I’m not proposing any new features and gettind rid of very few. Even stuff that is relatively useless and is there just for the flavoring, like the planet “view” and lore is kept there. A small change is the addition of a new button, “send fleet”.

Sending spaceships around is the essence of the game, but surprisingly, there’s no button to do it. The way to achieve it is to select a planet, change the slider to selecting how many rockets to send (I made the slider more explicit about “selecting”) and then dragging from one planet to another. While dragging is quite an efficient way of moving troops, it’s sometimes flaky (clicking and dragging on the map is also the way to navigate on it) and it’s hard to find that out by yourself unless you read the help menu. So in this change there’s an alternative way to achieve that: click the origin planet, select the rockets to send, click send fleet, and then click on the destination planet.

While it’s a lot more clicks to achieve the same task, it’s no doubt a better approach because it allows the user to figure out each step and understand what is happening on it. The old way of dragging should be kept, mostly as a shortcut for experienced users.

The principle here is that discoverability is more important than efficiency, and sometimes adding extra steps or UI elements to a flow is a net positive.

#5 Polish polish polish

A lot of developmnent work is just grinding details the user will never notice over an over. For example, for a text heavy interface, text in Dark Forest is quite messy. Certainly a better text placement algorithm would help avoid them one on top of the other. Another very important strategically important UI element is the radius circle, that, when you select a planet, tells you how far your ships can travel (the grey circles below), Ideally you should be able to see the full circles and they are selfexplanatory:

But in most circumstances you’ll see something more like a mess of lines and semicircles with very little explanation, because the text is off screen. Again, text placement algorithm is important.

When you select how many ships to send from a planet, a new yellow circle expands, going from 0 to 100%, which is sort of redundant with the current grey circles and gives a false impression that it represents how far your current troop can go. Instead a much more useful moving circle would be to show multiple lines showing absolute numbers: “by this far you’ll have a power of 500, here you’ll have a power of 150” which is the final information you need to decide where to send your fleet.

I could on in tons of small details like these that would help the UI get less confusing and many of these are probably already in the backlog of the developers. But my point is a design is not something you build on photoshop once and throw it over the wall to developers: it’s a constant interation of back and forth of finding small ways to improve your product experience, which you’ll only discovering by using it a lot. Be a user.

#6 Designers: learn to talk to developers

Most of this post is intended to developers or designers learning the ropes. But this is a point addressed to designers: know how to talk the language of your audience. Before jumping and trying to make a beautiful screen out of something ugly, try first really understanding the process in which decisions were made so that the UI looks like that.

Often designers see themselves as the “pure ideas” person, while developers see designers as someone to call when the house is already built so they’ll pick which color to paint the walls. Ideas are only as good as they can be implemented and they need to be understood and adopted to be implemented.

Notice that in this whole post I’ve avoided talking about the many ways in which I’d improve the game itself, or even trying to make a nicer looking planets and a fancy theme. Everyone who builds anything has plenty of ideas of their own, and if your fancy theme is a hassle to build, it will never get high priority. Sometimes a designer just needs to be the person tidying up the room after the party.

All icons come from open libraries like The Noun Project.

Arguably, the most important piece of real estate of the app is the header and menu and it contains the following elements:

• A MetaMask logo. Despite looking like an icon and being the first thing we see, it is not clickable nor provides any information

• A network switcher, using most of the space of the top bar

• An account switcher/menu. The same menu also contains links to add new accounts, import an account, connect hardware wallet, settings and info (which is just another menu inside settings menu). That’s a lot for a menu with an abstract icon.

• A connection status (new on 8.0.0) tells you information about which apps can see your account.

• Account title and address, clicking it will copy the address to the clipboard.

• Account menu, with the options to expand (opens MetaMask app in tab), account details page (more on that later), open in etherscan and a link to the connection menu (the same action as clicking on the connection status bar)

So, in a diagram format:

So, we have six click areas on the topbar opening four menus. However the noblest area, the top-left doesn’t provide any information or functionality and the largest click area on the top offers a functionality that is probably only used for more advanced users (how many dapp users want to set up a custom rpc or a localhost node?). Account switching is probably done more often by users (and we should encourage them to, for privacy!) but is hidden in a more neutral looking identicon. They are rather inconsistent in behavior too as some of these will create actions, others will expand menus. Say a user needs to see his seed phrase, it’s not very obvious that this path starts at the weird abstract green art on the top right corner.

Also the “account details” pane is interesting that it offers four actions, two of these will open a new tab (expand, etherscan), one of them will open the same menu that you get by clicking on the “connected apps” menu and finally one will open the “account details” pane.

And the Account details pane is a thing on its own: it replicates the same information we were looking at before, but now in a modal. It contains the following elements:

• the identicon: notice you see it twice now, as it’s still visible on the background

• account name: now it allows editing the name

• The address: shows more characters and unlike before, clicking on it won’t copy, just select it

• view on etherscan: notice it’s a duplicate of an action of the previous menu too!

• a QR code

• “export private key”: arguably a quite advanced feature, given that most users will just use seed phrases and individual private keys are less useful

This pane is opened from many places, including clicking on the “deposit” button and choosing “crypto”.

Suggestion #1: replace the “details” menu with an inline expansion

Expanded view could happen when you click the identicon, the name, or anywhere on the white bar (except the connection button and maybe the address). This would eliminate both the “account details” menu and “account view” overlay. Reducing the amounts of menus and overlays also reduces cognitive overlay from the user, as is one less place to remember where to navigate. This also keeps consistency, since we are just showing the same information we were showing before, just “bigger”. Actions like “expand” of “open in etherscan” are still just two clicks away. Clicking anywhere on that top bar would expand it, except clicking directly on the “connect” button or the address, which keeps the current behavior of copying the link.

We’ve also moved our little green friend icon to this bar, since identicons are a feature of an account, not the app as a whole. This of course means the top menu has a hole on it now. Let’s explore that.

Suggestion #2: unify the “switchers” menus

There are three main actions accessible on the top menus:

• Switch: change your current account or network

• Add: add a new account from seed, import account from file, connect hardware wallet

• Settings: since “info & help” is one level deep inside the main settings menu, it means this button essentially does the same as “settings”

Visually this could be divided like this:

The first big change I would defend is: unify switching accounts and networks. Not only this removes clutter from the app, but it also is good practice. You don’t want to be using your main account to sign transactions in a test network, this induces errors (“Help, I accidentally sent to my test account!”), can create replaying issues and reduces privacy as activity between networks can now be linked. Switching to a new network should also switch your accounts (but of course not the other way around). This would also help separate to the user what accounts are used for what and is in line with the common behavior of users so that you can more easily switch from say, playing with a main net app and then quickly switching to a test net app in another tab. When adding a new account the user should also select which network it is for, which also helps hide more advanced options like “localhost:8545”. In the very few cases in which a user might want to use the same account in two different networks, it should be allowed as an advanced feature, and upon first importing new accounts, it would be good for the app to check which accounts have balance or nonces on test networks.

Let’s call these concepts of “cards” in which each account is tied to a given network and contains a balance there. This is executed quite beautifully in MEW’s new wallet:

Applying the concepts of cards to MetaMask we would have an interface similar to the following:

The same functionality is present in the start, but we eliminated all intermediary modal menus, except for a much shorter “add account” menu. Clicking anywhere on the card header will expand it and show more options, clicking on the floating cards (and MetaMask logo) will expand them to allow a picker. Settings and Add account have clear icons. Not only the MetaMask logo is now in an even more important real estate, it serves an important functionality that is on-brand (access to your ethereum cards).

Some use of color can make the cards even more distinguishable. Colors can either be based on card type (main net, testnet, hardware wallet), random based on the address or they can be derived from the identicon itself (below right, we’re just expanding the icon and blurring it, so it works for any type of identicon including blockies)

I hope this exercise has been as useful for you to read it as it has been fun for me to work on it. I believe doing these changes would make the main navigation much more consistent, reduce the mental overhead required for users to figure out where stuff is and make the app experience even more interesting. Of course, the final design itself can be tweaked, animation can add another interesting navigation layer and it’s easy to see how it can be converted to mobile. Some tweaks can be done to show more relevant information, like if it’s a “MetaMask account” (derived from seed) or a hardware wallet. This reduces clicks, increases functionality and IMHO looks a lot more interesting.

Cheers and thanks for all your work, MetaMask team! Let’s keep building it together for a better and nicer ethereum!

I’m actually considering doing a whole new thread like Sunny’s, just with Brazilian historical trivia. Hands up if I should.

The Amazon is manmade. Its highly fertile soil is the result of purposefully mixing broken pottery, manure and fish bones for large scale agriculture. Many native species that were believed to be wild are now known to have been domesticated over thousands of years.

References:
Terra Preta
Domestication of plant species in the Amazon

The first European on the Amazon reported it densely populated, which was later considered an exaggeration. Recent deforestation have uncovered hundreds of geometrical patterns now understood to be remains of wooden temples (the region lack stones) of yet unknown civilizations.

‹1 / 4›

All the tribe members had bows, and when they saw white men coming down their river in a weird boat, they welcomed them with arrows. The Spaniards barely made it home alive, but were so impressed about the mythical women warriors they called them the “Amazons”.

Uncharacteristically for nomadic tribes, some Amazon people (Kambeba, Marajoara) have a class based society, further evidence they descended from a more complex agrarian society. The Kambeba even did cranial mods to differentiate themselves from other inferior "forest savages”.

‹1 / 3›

I hope I have convinced you that the idea that the Amazon was a pristine and unocupied land is a myth. I swear tomorrow's trivia will be on a slightly different take.

Reading suggestions on that topic:
en.wikipedia.org/wiki/Francisco_de_Orellana
en.wikipedia.org/wiki/Cambeba
en.wikipedia.org/wiki/Marajoara_culture

When the Pope proposed to divide the world between Portugal and Spain in 1493, King John II threatened war to push what was an arbitrary line in unknown sea 270 leagues to the west, later revealed to contain most of Brazil. This was probably not a coincidence.

The first European to arrive on Brazil was a Spaniard.
While there’s controversial evidence for some 1498 trips (and even earlier speculation) the first documented exploration of the Brazilian coast is of Vicente Pinzon, 2 months before the official Portuguese trip by Cabral.

‹1 / 2›

Cabral’s fleet to India, which claimed brazil for Portugal, was the largest ever assembled, 13 ships and 1500 men, more than Colombo, Pizarro, Vasco da Gama and Cortês expeditions combined. Yet it was given to a high noble with no sea experience as was the custom of the time.

Brazil, the netherlands and Italy shared the same King for 60 years. He was spanish.

Like many countries, Brazil celebrates Independence Day. But unlike others, it was actually encouraged by the Portuguese king to his son, who, seeing both colonies and kings were falling out of fashion, declared himself emperor of Brazil
Only his brother opposed.

During one of the few battles in the "indepence war”, the brazilian army was outnumbered and the commander ordered the bugle to call the withdrawal, but it played insted “cavalry, charge and kill”.
The Portuguese, fearing reinforcements had arrived, receded. There was no cavalry.

*independence

The trumpet player is commemorated on a comical statue in Ipanema on a street named after a big funder of the war, but unfortunately most people have no idea of his hilarious story.

Shortly after the Independence the whole process was accidentally reversed. Due to his father death, Peter the first, emperor of Brazil, was also crowned Peter the fourth, king of Portugal. He abdicated the Portuguese throne for his daughter, the only Brazilian queen ever.

‹1 / 2›

Half of all victims of the atlantic human trafficking trade were brought to Brazil. About 4-5 million enslaved africans were brought, 6x the total number of the United States. Brazil was also the last state in the Americas to abolish slavery.

After aboliton, all the files related to slavery were burned, theoretically to "allow the formerly enslaved to have a blank slate". Of course, quite conveniently for the former enslavers, this prevented any talk of reparations for their former victims.

Link to a new story of the time.

Brazil had its first “black” president in 1906. The country never had racial laws but racism manifested in society in other ways: his critics would call him a “mullato” but Nilo Peçanha’s family denied it and his photographs would be whitened. Only recently has this view changed.

The emperor was still popular when the republic started, and monarchy still enjoys some occasional popularity. A 1993 referendum to reinstate got 13% of the vote. The current “heir” was elected a congressman in 2018 and was considered for a VP for the current far-right government

There's currently a schism in the Brazilian “royal" family, due to a "scandalous” marriage of the Peter’s grandson with a commoner in 1908. As of 2020 there are two claimants for the non-existing throne of emperor of Brazil.

Whe wasn't even a "commoner”, she was a countess noblewoman from the Bohemian kingdom, but she had no shocked face royalty claim. I find the whole article particularly funny, a series of detailed wiki articles about people who did nothing but be born.

Only once in the history of Brazil was a democratically elected* president both succeeded and preceded by another democratically elected president. It happened in 2016.

*This excludes the first republic in which neither woman or poor people could vote. But even if we include that one, it doesn't get much better: the longest sucessions of presidents without a death, impeachment, or coup d'etat was 4 sucessions, 1894 to 1909.

It was actually 2010, 2016 is her impeachment. Had a brain short circuit there..

After Japan, the country with the second largest community of Japanese descendants is Brazil, about 1.5 million people.

Brazil’s first war as an independent country was with also newly independent Argentina, over who would control a bordering province. Both countries lost and thus was created the independent country of Uruguay.

Brazil still has some territorial disputes with Uruguay. One of them is a river island which was until 2011 inhabited by a single, ninety year old, farmer. When a fire broke there in 2009, firefighters from both countries came to the rescue. It’s currently uninhabited.

When the first Brazilian president since redemocratization visited Uruguay, he was met with a congressional protest against the “occupation” of the island. He knew nothing about it. Locals said there was an old stone house built by “dirty mark”. It was an old boundary marker.

France’s largest land border is with Brazil. It’s also Brazil’s second smallest border and the only part of Brazil visible on the euro note.
The border is serviced by a single two lanes bridge since 2017.

Thanks @TheOisinMoran for this one.

In 1997 Brazil signed a deal with NASA that would allow one astronaut on the ISS. It required the country to develop and build a metal rack to be mounted un space. Brazil never delivered. Instead in 2006 Brazil paid the Russians $11M for a ride. He’s the current science minister.

Brazil has been ruled by 16 kings, 2 emperors, 38 presidents (20 actually elected) and 3 republican prime ministers.

The country has a brief parliamentary phase during one single controversial presidential term in the 60’s.

While officially part of the Allies, the Brazilian Government during WWII was much more aligned with the Axis, having even deported Jewish Germans in brazil back to Nazi Germany. It only sent military forces by the end of 1944—less than 1000 brazilians died figthing in the war.

The current Brazilian president had over 50 impeachment requests. If one goes through, it will mean that half of all presidents elected in Brazil since the last constitution would’ve been impeached.
All impeachments have led to removal from office. We never needed to do it twice.

In 2013, protesters invaded the national congress, a start of a movement that ultimately led to the president stepping down.
While it still called a soft coup by some, it was never called insurgence, because protesters never openly planned to take hostages or murder politicians.

When compared in area, Brazil is about 10 trillion times larger than Room 711 of the Louvre, where the Mona Lisa is displayed.

Yet this single room has, in a normal average year, 25% more tourist visits.

Truthfully we only have indirect evidence of large settlements (see thread).

But I’ve always found curious that the earliest civilizations we know were building large stone temples in arid climates. Is that better for large cities or simply better for the archeological record?

Today marks the 200th anniversary of what was probably the most farcical “independence” war ever: after “winning” the “war” the country was ruled by the heir of the former king, who—plot twist—was the one who suggested it to his son in the first place.

Been a while since I've done one of these Trivias and it's not Brazil related but close enough. I just figured this cool fact:

Chile is almost as wide as its tall. In fact it's as close to a perfect square ratio (1.03) as Egypt, often considered the "squarest of countries".

‹1 / 2›

Some friends questioned the calculation. There are many ways to say "wide" as there are no rectangles in a sphere. When measuring the great circle distance from westernmost point (Moto Nui) to easternmost point (Terra del Fuego), Chile is actually wider than tall!

Meanwhile we are happy to see that some integrations we’ve being working on are going live, namely Kickback and Gnosis Safe Multisig.

But wait, didn’t we already announce we were using Gnosis Safe? To explain, let’s clarify some terms.

Besides their prediction markets and exchanges, the Ethereum development company Gnosis has also built two widely used multisig contract wallets: the original Gnosis multisig and the newer Gnosis Safe, which supports etherless transactions. The latter is what we use internally as our contract-based accounts.

But Gnosis also offers Gnosis Safe as a frontend service for teams, so they have an app named “Gnosis Safe Multisig” (no relation to the previous “Gnosis Multisig”). The Gnosis Safe Multisig app, which was formerly named “Gnosis Safe for Teams”, allows you to create and manage safes from MetaMask or other service providers, now including UniLogin, which is itself a multisig.

But why?

Is this just a curiosity to make a point about daisy-chaining contracts together? Not at all! In fact, the idea of modularity and that every account would eventually be a rich, smart account has permeated Ethereum development since the early days. You can see this from this screenshot from my 2014 presentation of a vision for an Ethereum browser at Devcon0. In fact, when Geth was first developing account management, it was believed that public key pair accounts would be just a temporary measure and that in less than a year most people would have migrated to what we then called “proxy accounts.”

This goes deep into the heart of what an “identity” is. What makes you “you” online?

On the traditional web, it’s about authorization: proving to a central server within their reasonable bounds that you are the correct person, with increasingly hard challenges (a session cookie and, if that fails, a username and password, then a “forgot password” flow, and then sometimes you might be able to escalate it to a human in the help desk).

In the crypto space, traditionally it has been a very binary choice: if you have the private key, then those are your coins. If you lose access to your key, or if someone else gets access to that key, then too bad, you’ve lost them.

It’s our belief that in a decentralized world, the concept of “you” will be a constellation of devices and keys that all agree to slowly expand. Your phone, your laptop, your tablet, an email, a smart card, maybe someday a smart passport, your watch, eyeglasses, or any other smart wearable will be added to this constellation of your identity. Each device (and each app in each device) holds a single untransferable key that is authorized to do a few actions on your behalf and enables you to vote to add or remove devices to that identity or expand these permissions. Your digital identity is a democracy made of your devices.

If Alice and Bob wants to start a common enterprise, let’s say a bar and restaurant called “Foo,” they should be able to control that identity together in a similar fashion: for some actions (like posting on a social media app) one of the keys should be enough to authorize it, for other more important actions (like moving funds) they would need multiple approvals.

What if now the Foo Bar wants to vote in a trade union of local bars? Or if the local trade unions want to do an assembly vote on state level? Not necessarily all of these collective contracts would follow the same rules, but the important lesson is that they should be infinitely scalable, from the small decision of which of your devices to authorize a transaction, up to who has a right to vote on the global election.

In practice: how do we get there?

Enough with the theory, how does it look today?

1. Go to the Gnosis Safe app.

2. Click connect to wallet > Show More > UniLogin.

3. Select your username. If you already have a login it will connect you to one, otherwise it will create one for you.

4. If you are in the US, you can now use Apple Pay, thanks to our Wyre integration! Otherwise you can always use the excellent Ramp in Europe or just use crypto if you are already onboarded.

As soon as the transfer is detected, a new account will be created for you, which uses Gnosis Safe behind the scenes. Now to create a new Gnosis Safe, just click “create new safe” and then follow the instructions on the page. When you are asked for a list of owners instead of hunting down Ethereum addresses to copy paste, just type your UniLogin username! Whenever you are using UniLogin you always get assigned an ENS name on account creation, and since this page supports ENS lookups, all you need to do is type the given name and the right account will be found automatically.

This will create your second level multisig, from your personal level multisig account. It doesn’t look that complicated does it? If you’re curious to see how it looks like technically, check the transaction that generates the safe, from the first one.

Warning: Don’t put more than a few dollars into your account yet.

Some browsers (like Safari), are changing their approach to local storage and are clearing it with more frequency in order to combat tracking. So you might get logged out and without access to your main account. To make sure that this doesn’t happen, make sure to download the “recovery” key PDF.

This should not happen in most browsers at the moment but we are changing the user flow to make sure this is more prominent to avoid user losses.

Also try it on Kickback!

We are also happy you can use UniLogin with our good friends from Kickback too. Just go to kickback.events and select “UniLogin” as your wallet option.

Integration with Blocknative

Both Kickback and Gnosis safe use Blocknative’s OnBoard.js, which is why if you are already using it, add one configuration line to integrate with your app (see line 5 in the snippet below):

The Blocknative team helped us to improve usability by giving users instant feedback during onboarding when ether is being transferred into an account, even before a transaction is mined.

Follow us!

To make sure you don’t miss the next posts in the series, follow us Medium and Twitter.

Pilot program

Still not signed-up for our Beta program? Fix it!

Join our Pilot program 👮🏽 🛩

Turtles All the Way Down: Multisigs Owning Multisigs was originally published in UniLogin on Medium, where people are continuing the conversation by highlighting and responding to this story.

"What’s the chance that the name you’re looking for is already taken?"

We can assume that the ability to find available domains should be a worthy goal. Of course, the problem is that the theoretical limit is infinite. But that’s not so in smaller lenght domains.

Uniswap uses a rather straightforward formula: x * y = k.

Where k is a constant and x and y are the variables. The interesting thing about the formula is that it’s an asymptote, in which the price tends to either infinite or almost zero, but never reaches either. How would this work for ENS?

price of a domain * number of domains of that same length = constant K

This means that the very last domain will be infinitely expensive, the very first infinitely cheap, according to a curve we set. So for instance, there are 17,576 three-letter domain (In the english alphabet). Let’s suppose we set the K of this tranch at around 35,000 (2 * 26 * 26 * 26). It would mean that:

If only 1000 three-letter names are registered (less than 10%), then each registration would cost about 2.1 ether.
If 7000 names are (about 50% occupancy) the price surges to 3.5 ether
The 10,000th name will cost 5 ether
If there are 15,000 names taken, then it would cost 17.5 ether
If 17k names were registered (almost 90%) then each new name costs 60 ether.

This could be applied to annual fees going forward, this way it encourages that there will always be a nice amount of names available for registration. Maybe by releasing a name, you get a portion of that amount, meaning that if the prices are going up, you have good reason to drop you unused names. There would be tranches for 3-6 letter names, and then we could use the 6 letter price for everything else since there are over 300 millions of them. This would also mean that for long domains (or non-english ones) prices would always be a small amount.

Would this make sense?

Ethereum is changing, and the Ethereum Foundation is rightly changing with it.

While the high centralization of the early years of the foundation might have been crucial for Ethereum to develop and ship, it was also a great source of criticism as it was antithetical of decentralization.

At Devcon4, Aya Miyaguchi, the new Executive Director of the foundation, gave a beautiful talk clearly influenced by Zen Buddhism on her management style.

Aya believes there was more value to be created by subtraction than addition. The foundation aimed to be smaller, have less power, less resources, and to do it by giving it away as grants.

No longer there would be “official” in-house teams versus external contributors, the foundation would be a financier of everyone inside and outside, and the internal teams had to compete for these resources like everyone else.

Had anyone asked me about where the foundation should go a few years prior and how it should manage their resources, I would have described exactly that model. I know, because they did ask. Before Aya became the director, we all had multiple conversations, both through official channels and in informal corridor meetings at conferences, to describe what everyone wanted to see the foundation become, and that was usually the answer. Teams wanted more autonomy on their own budget, to do more experiments without having to ask permission for every new hire, or planned conference. And that’s what they got.

Of course, there’s another side to this: if you get more autonomy, you also take more risks. And if the resources are going to more teams, there’s more competition for them

These might actually be good side effects, but they’re not easy on the receiving side. For example, for years I led the Mist team, a browser that would connect together a bunch of Ethereum technologies to create our vision for Web3. While it was used by a niche of Ethereum enthusiast, it failed any mainstream traction (well, depending on your definition of “mainstream”, no one else really reached that yet either) — and we were flooded by serious security vulnerabilities.

The team realized that, while the biggest security risks were in the browser component, there was still a lot of value on just having one single place that would help connect and manage all the different Ethereum components in one single app, which is now called Grid. Meanwhile, I started to explore what were the real obstacles to mainstream adoption and started a path that I named “universal logins.” At some point I realized the Grid team would have a better chance of getting their full budget if I took myself out of their budget, so I did.

And that was it. I took myself out of any team’s budget in the Ethereum Foundation. Nobody asked me to do it, and I didn’t tell anyone other than the accounting department (and Twitter).

The foundation is quite unique in that I haven’t had a “boss” in the traditional sense in many years. You did your job, you sent an invoice to accounting, which often involves many different people and sometimes different companies in different jurisdictions, and eventually you got paid. Once a year they expect you to tell the world at Devcon what you have been doing. And once a year a different set of people will debate the budget of your team and what you’re doing. Who’s “in” the foundation and out of it is a hard distinction to make. Is it who has an ethereum-dot-org email addresses, or maybe those who get tickets to Devcon, or maybe people who have access to the Discord?

Figuring out how many people actually work at the foundation was in fact one of the first challenges Aya had to take on: it was not uncommon that some people who had active contracts would disappear for months on end into a Github project and suddenly come out of it with a three month invoice — or mabe not even that. I personally had the case of a team member who never formally quit, was never fired, just ghosted out, stopped responding, and stopped sending invoices. It’s a weird side effect of remote work.

On that front, the new grants model is superior. It doesn’t really matter how many people worked on a given project: money goes in, code goes out. If the result isn’t good, you just stop sending money.

In short: the foundation is moving into a grants style organization. My old project was discontinued and I didn’t want to weigh down the new project’s chances of getting that funding by having me on their budget. And that would free more of my time to dedicate to what I think is the biggest issue on the ecosystem: user on-boarding.

Why does Ethereum on-boarding suck so much?

A year ago, Metamask was pretty much the only game in town on desktop. And while there was a dozen or so mobile apps, everyone was following its footsteps: for every new app, you create a new private key, backup that seed phrase, and transfer ETH into it. Rinse and repeat, every single time.

Not only is the on-boarding process usually long and complicated—you need ETH, which usually requires a credit card or an account in an exchange, which often require official documents and multiple days wait—but you need to do it every time you install a new app! If you already have ETH (or even BTC) the process is usually faster, but you still usually need to think about private keys, backups, etc.

In the year since my talk in Toronto on what is now called meta-transactions, the landscape has changed dramatically, and we’re seeing more wallets taking that challenge seriously. Even wallets that still create a private key for each user are now deferring showing the user an interface for backing it up after they’ve had some experience with it and actually own anything of value.

But still we have a main problem: every app repeats the same on-boarding process. Trying a new app often means starting everything over. Once a user is on-boarded on Ethereum, we need to be able to have them be able to try new apps without having to either transfer money or share their private key.

When building Mist, our challenge was always to build something for the type of geek that would install Firefox on their mom’s computer just because Internet Explorer was terrible (I hope that metaphor doesn’t age me too much). It was never the most newbie user, but someone a bit more curious and technical, which was, at the time, the least technical savvy person we could reach with the tech we had in mind.

I believe we have the tools now to reach a much wider and more audience now: of people who are outside the crypto sphere and want to try something really magical with their money. That new challenge is now universallogin.io.

Hope you follow me on that new adventure. If you’re in Berlin between 19–23 august, come catch up, I’ll be giving at least four talks:

• Monday 19th: Metacartel Demo day

• Tuesday 20th: #BuildBetter

• Wednesday 21st: Web3 Summit

• Thursday 22nd: Dappcon

Where Ethereum is Going was originally published in UniLogin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Personally it feels like yesterday, but I’ve been working on Mist for over four years. While I’m proud of all the accomplishments we achieved in this time advancing the usability of Ethereum and sharing a vision for web3, we feel Mist, the browser has outlived it’s usefulness: the ecosystem has matured so much that now the user has tons of great options of wallets and browsers on both mobile and desktop. At the same time, the message of how crypto can make a better web has reached so far that now great names like Samsung, Opera and Brave are all focused on integrating web3 features on their roadmap.

Not all were roses, and in our way we faced some extreme security challenges that forced us to reevaluate our whole roadmap and question if keeping the project alive would be a good use of the Ethereum Foundation resources. We decided then to take everything that was valuable from Mist and roll into separate projects, but the main browser app should be considered deprecated and insecure. For more details on what these are, follow on.

What we did right

A vision of a web3 browser always has been essential to the ethereum mission, so much that when we first set up the huge milestones for Ethereum, “Metropolis” would be one in which we had easy, working web3 browsers. More than that, Mist and the accompanying “Ethereum Wallet” app were crucial in these milestones:

• It was the wallet that launched the token standard. Fabian Vogelsteller, writer of the ERC20 draft, was also the lead developer of Mist and we decided to use it to break the chicken and egg problem of standards: we released a version of the wallet that supported tokens almost at the same time we published the token standard, and it also came with an easy way to write and deploy your own tokens

• Ethereum Wallet paved the way on how to build a Dapp. While it was a separate downloadble from Mist, it was built completely as web app and the lessons on how to communicate securely with a browser layer really helped pave the way how we deal with that today

• First GUI wallet that enabled early users to use ethereum and import their presale keys, back when it was only available through command line (or some exchanges)

• First wallet to set and encourage the Blockie Identicon standard

• First wallet to develop and promote the CamelCase Checksum (an idea by Vitalik)

• First wallet to allow easy deployment of contracts (long before Remix had a web interface)

• First wallet to create a visual interface for interacting with any contract from pure ABI (and for many years, the only one)

• First browser to support ENS domains without using gateways

• First browser to support Swarm Hosted websites

• Web3.js, a library used by many apps as a way to interact with ethereum via javascript, was created by the team for Mist and then made available for others

These breakthroughs really paved the way to make Ethereum more usable for the first years, and the fact that it was developed in close proximity with the other teams helped their schedule along. The Ethereum Wallet was always built as a web-based app, and this has helped the team learn a lot about how the Web3 should work, which later evolved into other standards. Small things like Geth’s “signAndSend” API, were developed precisely because Mist was able to use and provide feedback to the team.

During the early prototypes we had designs for dashboards, appstores, integrated code audit checks, identity as first class citizens, personal tokens, DAOs, prediction markets, and many other things that are only now started to see the light. One should not see this as “being too early” but as a sober reminder of how long projects take to mature. We couldn’t built most of these tools then, and we could only build a few of them today, because they depend on a more broad ecosystem. You can’t build it all in one day, in one team, and you should beware of anyone that promises you otherwise.

What we did wrong

Our biggest speed bumps were always mainly two: syncing a node and relying on Electron. Syncing a full node was doable in the early years, but soon became a chore that would take hours. These issues started being solved in 2017 when light client became reliable, and then in 2018 we also compromised and added a remote node (INFURA) connection that would seamlessly switch between nodes; we strongly believe the ecosystem needs a vast number of nodes being run by users. This issue led us to lose a lot of our early users who voted with their feet to use apps with hosted remote nodes. While decentralization and convenience are always constant struggles with both sides having downsides, it certainly something that can be fixed in the long term, with both mixed remote/local solutions like we used and with the advancement of light stateless clients. But this was not the case for the security vulnerabilities brought by electron.

Electron is a great framework for webapps on the desktop, built for apps that used their own trusted javascript files. But when you are building a browser, you are, by definition, running random code from unknown people all around the world. This is tricky. Also, for most of our history together, electron was not updated frequently and even when it was, it was still running several versions behind chromium, which meant that often the latest version of Mist was running an engine several months out of date. Google tends to publish vulnerabilities it found after six months of releasing a fix, and at that point we were still stuck with the one-hundred-day exploit open, leading to a situation where we were paying from our bug bounties fund from people who simply took known vulnerabilities in chrome and applied them to us. We had a professional audit of Mist and they were able to discover multiple vulnerabilities that were fixed, none very dangerous but in late last year we received notice of a few very serious bugs: ones that would allow an attacker to take control of your computer (and your crypto keys) by simply visiting an untrusted website. This is very bad.

We released a fixed version immediately, but then others similar attacks were revealed and at some point our own internal security team recommended that we not allow the user to navigate to untrusted websites — which is the whole point of a browser. We put an alert on the app and started looking for alternatives.

We explored many alternatives (like Tau, which uses Chrome Embedded Framework instead of Electron), but still we realized that the amount of human resources needed to keep and maintain a safe browser were far larger than our team could support.

Meanwhile, the ecosystem has also evolved a lot since the early years: Brave (which also started as an electron app but now moved to a full chromium fork) is a solid browser with crypto integration and a great companion to Metamask. In the mobile space, wonderful options were launched in the last couple years: ethereum native apps like Coinbase Wallet (formerly Toshi) and classic browsers vendors like Opera now have a web3 integration. This has lead us to believe that other browser developers have more resources and are closer to having web3 features natively, than we were of having a secure browser framework.

What nobody got right

We still believe there’s a long road ahead for the web3 vision. These are things that we haven’t seen done correctly by anyone so far:

• IPFS/Swarm integration on the browser URL. Sadly, most ethereum apps still use traditional servers that don’t have the immutability guarantees of hash addressing content. If you are building an app or a wallet, consider hosting on IPFS so users can be sure the underlying code can’t change underneath them and break things. In our experience, this not solely the fault of browser vendors, but also an issue with the maturity of the underlying technologies: we successfully implemented swarm hosting over two years ago, but since then both the protocol and their network changed drastically. Sometimes being too early to adopt a changing protocol is a hindrance. Brave Browser is making good progress on this.

• More use of ENS: we believe ENS (or other decentralized DNS alternative, like handshake) offer much better usability when it comes to adding addresses and domains. We have added ENS support to all our address fields in the wallet so you can use a name whenever you added an address. But in our experience, doing it unilaterally is not enough: you also have to provide easy ways for the user to register their own names, in a similar way that we launched token support by not only providing an easy way to add tokens, but also to create them. A good example of progress on this is Argent—inspired by Universal Logins (another project that came out of the Mist team)—which gives each new user their own username as part of the onboarding.

• Wallet is just another app, identity is not. We believe we made the right decision when we tried our best to make the wallet just another app on Mist. We also structured the app to focus on Apps that you keep coming back to, and not transient documents you read (which is why we always used sidebar icons instead of tabs for example). But we now realize that the real first class citizen should not be the wallet, but your identity. It’s important for any browser vendor to integrate identity in a way that is both private but universally accessible. This way you shouldn’t need to create a new identity on every app, and you should keep control of that information. For a good approach on keeping information private and yet portable, check the threebox project.

What now?

We are sunsetting Mist the browser and will no longer actively support it (but can revisit this decision for occasional security and fork upgrades), but a lot of our work in the past years will be reused, thanks to a great effort of modularizing and modernizing our own code. We are basically splitting Mist in multiple component pieces:

• Node management: during the last year we revamped a lot of the internal node management of Mist and how it downloads and runs new versions of geth, swarm, whisper etc. We are now working to release that as a separate app to help developers manage multiple versions, called Grid.

• Reusable React UI elements: we carefully rewrote most of our components in a reusable library called “Ethereum React Components” that can be used as a starting point for other apps. You can check them all live on our storybook.

• Confirmation windows: we refactored the most important piece of the UI for a wallet, the transaction confirmation, in which the user must understand at a glance what’s happening. We are now working to integrate these interface improvements to Geth’s own key management app, Clef.

• App update manager: we refactored mist’s self update mechanism in a general App Manager for unified update mechanism for binaries with hot updating and signature verification.

• Package Signer: we also separated a different library that allows you to sign and deliver updates with nothing but an ethereum key, allowing projects to prove the validity of software in a more decentralized way.

• Wallet: the app known as ethereum wallet is actually a webapp, usable by either mist or metamask at wallet.ethereum.org. That code is outdated and the user experience underwhelming, but we believe we can contribute with the Universal Login project in an open source non-custodial but safe wallet.

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F1lH4q1-Ba0k%3Ffeature%3Doembed&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D1lH4q1-Ba0k&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F1lH4q1-Ba0k%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

What’s next?

The Mist team will continue working together, but our mission now instead of building a single app will be to focus on improving and helping the user experience and front-end of other teams in the Ethereum Foundation. It’s sad for us to see the Mist era coming to a close, but we are happy that one of the reasons for this is that the ecosystem has so many other worthy options. Ultimately, it’s important for our team to help the Ethereum Foundation focus on an area we believe deserves more of our attention and skill sets and we believe our experience in building more accessible front-end interfaces for ethereum apps will be precious.

Our short term goals are to release Grid and some of the other mentioned offshoots of Mist. On the medium term we want to collaborate more with other teams within the Ethereum Foundation, in which teams usually work in isolation, and to lend our our expertise in design, user experience, and front-end architecture, to improve design and usability cross sectionally on all projects.

What to do with funds on Mist?

Mist and the Ethereum Wallet are user-custodial wallets, meaning all your keys are kept on your own device and you have full control of them, in a file format that is compatible with other ethereum wallets. While there’s no need for any action now, if you want to use them for o, we recommend you migrate these keys to Mycrypto, Metamask and others we have written this handy Mist migration guide.

I spent a half a day and was able to build a contract that keeps DAI in compound, but withdraws when it wants to make specific payments. I added yearly salaries of all team members and spent another half day in making a nice interface so they can request payment at anytime.

I recently posted how after being paid in BTC and ETH I was now receiving in DAI. But there's a lot more to the story. In fact my whole team has been receiving in ether for years but we had a lot of trouble doing so.

First of all, it's actually quite hard – purposefully – to move funds. Some of the bigger wallets the foundation has have been an original multisig code, which is safe but only works with command line tools. At some point we had to wait for busy people like Vitalik to sign a tx.

Also, payments in ether are complicated for accounting due to volatility. Do you use the exchange rate of the invoice or the day the tx is sent? People send invoices in different days, it takes some time for the person responsible to go through payments, it's not trivial.

The result is that for a long time the decision was that the exchange rate used would always be either the 1st or 15th of the invoiced month, depending on when the invoice arrived. It simplified things for one side, but also created an inconvenience for those being paid.

In highly volatile months you could receive 30% more or 50% less than you expected. While it can lead to some good surprises, people don't like to gamble their salary usually. So I proposed a solution for my own team: they would invoice to a buffer contract.

The buffer would pay them immediately on the latest exchange rate and then at some point it would be paid back at whatever exchange it was sent to. It had other functions too, requiring secondary approval, listing individual invoices, even a place to put swarm files.

But mostly it became just a way to make sure everyone got paid on time, while it reduced the overhead from HR people that now only had to make one transaction to pay many invoices, since everyone asked to the same address. But it did increase my overhead as I now had to manage it

Since it required a 3 step process for paying (submit, approve, execute), it would meant to pay 4 people I would need to sign 12 transactions or more (I also had to manually add the day rate). The move to DAI could help most of these points.

At first I considered using Aragon's "Payroll" app, which inspired the idea of setting a yearly salary and allow you to be paid per block. But that app is under development and the buffer dai would stay locked on the contract, not generating interest. So I decided to build my own

As a final touch, I set the default function to pay all amounts due and be public, so it allows a service like ethereum alarm clock to schedule a call for a given day of the month. We recently tested today and it all worked like a charm. Here's the code.

The first devcon (obviously we start counting at 0) could barely be called a “conference” it was mostly a team retreat. About 50 people, many meeting together for the first time, presenting their work

Devcon1 was in London, about 300 people. The whole conference would fit in the main hall at the National House Smíchov which had three more floors of rooms and hosted many satellite events (Cryptolife Hackaton, Philosophers Salon, Magicians council, the ECF alumni show & tell).

‹1 / 2›

Devcon2 was in Shanghai and doubled in size to about 700 people. That’s the same headcount as the Prism sidestage, which ran on day 0 at full capacity.

‹1 / 2›

Devcon3, Cancun was more than twice the size of the year before, about 1500-2000 attendants, and for the first time had two parallel tracks. (I don’t have any picture of the room as I wasn’t there for personal reasons)

This years devcon had 8 parallel tracks!

And also two rooms running person to person events and a series of rooms available for setting up ad hoc meetings. And of course, the Neptune room, where an artist was giving a constant performance of ambient sounds where people could go to relax and do quiet work.

Those ad-hoc, off-schedule meetings where crucial as they allowed teams that wanted to coordinate changes or discuss standards to do anytime. I’ve personally seen a Meta-transactions roundtable, news interviews and Amir Taaki giving a talk on the fall of western civilization.

‹1 / 2›

Devcon4 has about 3000 badges printed. I personally hope it doesn’t double in size again, because a 6000 person conference sounds unmanageable - and because often the main stage was quite empty, with most people crowding in the smaller and more personal workshops

In those you had more opportunities to interact with the presenters—some people skipped talks altogether and were just mainly networking around the (great) food tables.

If there’s demand, I hope it grows horizontally, with more independently organized events to take on the overflow of devcon attendees. Maybe we can come up with a system where the badges work more like passports that can be stamped and used as ID in other events.

But as so many have said before me, the organization was fantastic. I felt it captured the intimate person to person work meetings of the early devcons, with space for the big messages from keynote speakers. Congrats to @mames and @mi_ayako
See you all again at #DevCon5!

If you like reading about novel economic ideas in crypto (and since you’re reading this, I assume you do) then you are probably aware of “Token Curated Registries”, a token incentivization mechanism to help curate lists of stuff. The short version is that a given list (say, “best restaurants in town” or “funniest star wars prequel memes”) is maintained by a community of token holders which add new items by proposing a new entrant and making bets either the majority will accept that as part of the list. The incentive for small token holders is to only propose items they think are likely to be accepted by the majority (otherwise they’ll lose a bit of their stake) and the incentive for large token holders is to make sure the list is interesting and valuable, otherwise the tokens themselves would become worthless.

While it hasn’t been tested in any real application, TCRs have been subject to many improvements as well as criticism, specially regarding their aplicability to subjective lists whose clear answer either doesn’t exist or is very expensive to discover. One of the main problems is also the classic tragedy of the commons: tokens themselves have no value except for the ability to buy your place in the list for exposure of your business (in the case of the restaurant review, for example), and while token holders have a collective long term incentive to keep the list high quality, they can also have a short term profit by accepting money from an advertiser to either sell or temporarily lend their tokens for a vote. I’m mostly interested in TCRs precisely for building subjective lists that have no clear answer, so I’d like to propose a solution for that which would create new incentives for token holders to keep hodling.

Curved Token Bonding

A common feature of TCRs is that the voting tokens don’t have a fixed supply and instead are generated by depositing a base token (which can be ether, dai, or even another token) and then increasing the unit token price as its supply grows.

This has a few benefits over having a fixed supply set by mining or an ICO: first it means that owning 51% of the tokens doesn’t guarantee winning a vote, since the total supply is dinamic. It also guarantees an external value and liquidity for tokens, since they can always be traded to and from another more liquid token. It also creates interesting ways to fight back a whale: if someone buys a lot of tokens to sway a vote, the community can always generate more tokens to vote against it, or simply sell off their own tokens immediately, therefore devaluing the tokens held by the “attacker”.

The assumption of the bonding curve is that the total supply of tokens always equate the funds held, therefore if everyone sold all tokens, the total amount of money going in would be equal to the amount of money going out. The distribution of money for each participant would be different, depending on when they got in and out, which makes the whole system a zero-sum game that rewards those who got in early and got out at the top, making it very similar to a pyramid, or a “pump and dump” scheme in which all profit comes at expense of new members.

Of course, if someone loses access to their account (or the participant leaves the community and doesn’t come back) then the amount of tokens will never go back to 0. The lost funds guarantee that you will never be the last bag holder, but these funds are forever locked.

Sponsored Burning

But what if we break the assumption that all funds going in must be equal to the ones going out?

Of course, we can’t have more money going out than it came in, but let’s assume there is a function that enables someone to add to the total supply of funds held by the tokens, without getting any tokens back. This would mean that if every token holder decided to sell their tokens back to the system, the total amount distributed to token holders would be more than what they all bought for. If the first person to enter was also the last person to exit, they would still go home with a profit. Even if a mass exit doesn’t occur, it means that by just holding tokens, without any new member needing to come in, your own tokens have increased in value.

But why would someone make what is essentially a donation to the token holders? That goes back to the purpose of TCRs in the first place: curating lists of stuff. Not only restaurant reviews but, Google result pages, Subreddits, Twitter hashtags, even your social media is a curated list (curated by you).

And every single one of these pages has some sort of sponsorship. Advertising is traditionally seen as adversarial for users, or at least as the necessary evil that users must tolerate in order to keep the site running. Users increasingly want not to be tracked, and to block ads, but website owners need the revenue so they add increasingly clever and intrusive methods to force ads into users.

Let’s suppose a website owner tries to make all their users token owners of their favorite lists (which avoids having to ask for them to buy it), and then users can vote on which stuff belongs in their lists. The more popular and active lists will bring more audience which will bring ad interest. Now let’s suppose that in each list there is a clearly demarcated ad space which is distributed in proportion to the amounts of sponsored burns made in the last 30 days. If $7 dollars were added to the token supply via sponsored burns this week, then if you make a $3 contribution you’ll get 30% of the ad views.

But who gets to enforce that? The beauty of this system is that we are supposing that there isn’t any single “owner” of the token curated content that needs to follow strict ad rules or keep track of clicks and views, anyone can create an app or website and show the content that was curated by the token holders. But since now token holders gain value from sponsorship, and advertisers will only want to sponsor if they get exposure, then users themselves will demand app builders to add sponsorship slots. These in turn can be adapted to the medium: token curated lists of audio can measure their sponsors in seconds, while scrolling feed based lists can add them to probability of appearing on fixed slots.

Conclusion

Sponsored burning proposes a new method of revenue participants in Token Curated Registries that rely on Token Bonded Curves. Sponsoring can better align the incentives of token holders to create a better quality content specially for subjective lists, by adding an external profit model which doesn’t require token holders to sell or rent their tokens. I hope that this model can allow us to create decentralized communities for curated content that don’t need to resort to intrusive advertising to keep the client developer lights running.

To read more about my ideas on how to create these communities read the Eternal Septembers paper and the story on how that came about.

When I was introduced to Preethi Kasireddy’s “TruStory” project by a fellow acquaintance, what caught my attention was how similar it was to something I’ve been brewing in my head for a while, after reading a lot about Token Curated Registries. Preethi and I were trying to solve different problems—arguably she was worried about a much more important issue, on how to save the free press in the “post-truth” era—but we were working on very similar solutions. I started writing back an email giving feedback about the state of TruStory as she had shown me and soon I ended up writing my first “White Paper™”. I didn’t want to change what she was working on, just wanted to show a complete solution to a different problem that could help a few areas of her own project. We kept on talking multiple times and I agreed to have a formal position of advisor, which is something I’ve repeatedly turned down.

Preethi’s work has been flying under the radar, until she was able to close a round of funding without an ICO (much smaller amount than the exuberance of most ICOs) and got some positive press. And then, a few weeks later I started to see a lot of bad press from many in bitcoin twitter. So I’d like to talk about Token Curated Registries, Reddit, my paper, TruStory and my relationship with that project.

Eternal Septembers

I started my crypto career, met great friends, got a job, all thanks to Reddit, yet I can barely visit r/ethereum anymore. The community there has grown exponentially, which is great, but it has also been transformed in the process, a seemingly inevitable transition that befalls any community once the rate at which new users are added is faster than how they can accomodate and learn the old “culture” of the community. This is not unique to Reddit, but an overall phenomenon on the Internet (and in other areas) and it has a name: eternal september.

This is usually managed by heavy moderation, but it usually lends to concentration of power in the hands of moderators and stiffle free debate.

I believe it can be done better which is why I wrote the paper “The Eternal Septembers” which goes into more details but here’s a short version of it:

• Every community is created by a having a different “reputation token” that you need to own before you post about it

• Instead of moderators, any user can post a thread to a topic and stake a bit of their reputation on it. Others that “upvote” it are also staking their reputation that that content belongs on that community. If someone believes it doesn’t belong there, they can make a mod request by stake some reputation against it.

• After a given set of time, whichever side has more stake wins and the reputation tokens redistributed accordingly, and the content either remains or is removed

• The older and more active a user is, the more reputation of that token they have, but often these are not active, meaning that “voting” is actually a bet on “how would the members of this original community vote on this issue” meaning that the community amplifies it’s early culture and multiplies them to the new users

• Tokens are bonded to an inflationary base token, which dilutes away the value of inactive members and redistributes it to active users

There are some other interesting aspects on the paper, on how it scales by using a lot of off-chain betting, how it can force people to bond to some base values of “harmless content”, and how the tokens can create an actual value to holders by using a novel form of advertising called “sponsored burning”. For more details, read the paper.

TruStory

I never did any work on Eternal September since sending it to Preethi and AFAIK nobody is (if you want to work on it, let me know). She is, instead, building something completely different and in a ways, more important. While the problem I started with was “my subreddit isn’t what it used to be”, hers is the Fake News™ issue, or “how can we prevent the most important network of free speech ever built to be used as vector of false stories that undermine the society that built it?”. When I met her, she had a lot of the basics of stake-voting and tokenizing reputation, but through our talks she started considering many elements of TCRs, bonded curves and off-chain disputes.

I am very passionate about the issue of the rapid proliferation of untrue but outrageous content on social networks: it’s a real problem affecting democracies everywhere, one that arises directly from values I deeply believe in (that everyone in the world should have access to a global network for free speech), yet the “solutions” currently proposed are methods I deeply dissaprove of (giving central authorities–be them private corporations or governments–tools to censor and control the flow of information). In short: it’s an issue we created with the tools we built (a free Internet) and we need to solve them ourselves without risking fundamental freedoms or someone else will.

After talking multiple times over the phone I decided to accept an invitation to be a technical advisor for TruStory. What that means is that I am in contact with the team and offer advice on how to deal with technical challenges, as well as voice my opinion about many issues. Which is sort of what I already do unofficially for many other teams. This does not mean I am aware of every decision made, audit their finances or every line of code, it does not mean that I endorse any sort of investment in the company or any token they might launch. I might be compensated in some form for my work (honestly I have no idea about values) so it only means that if it all goes bust, we’re doing this together. This also doesn’t mean that I will publicize the project: in fact I actually avoid talking about it online because of my connection to them, and this very post is an attempt to put that on the record.

I am a fan of the project and root for it, like I root for many other projects in the space. And while I avoid being “advisor” as much as I can, I do like giving advice to people who need it, so if you find me in a conference, feel free to tell me about your project.

Firstly, the White Hat hackers have shown to be extremely competent and I feel confident they would have been able to rescue at least 70%-90% of the funds back to dao token holders (as they did).

They knew it was a possibility then, but they didn’t want that pressure on them.

Also a Fork was sold as the “clean” option, the one that would solve the problem quickly so that everyone could get back to work. Instead the fork created arguments that persist to this day. While ETH/ETC communities have been mostly at peace, that animosity is still brought up.

The values back then felt gigantic and community-threatening. I don’t think they were. I remember a common recommendation post hack never to store more than a million dollars in a single smart contract. Those figures are laughable now.

I’m also confident looking back that even if it had not the reentrancy bug or governance problems, the DAO was doomed. Think about the ICO craze that came later, but one in which people could vote (and buy votes!) to invest in them with other people’s money. Not good.

But we have indeed learned a lot about forks. Before it, forking an existing blockchain was a theoretical possibility that most people believed would threaten the original chain on a “there can only be one” combat. I wonder if Bitcoin Cash/Gold would have happened.

Most importantly, we learned how resilient blockchains are. Ethereum Classic is what happens when original developers and a whole community decide to leave an old chain to die in the side of the road. Instead it survived and came back with a vengeance. It’s inspiring really.

But also, we learned that blockchains are replaceable by a community on top of it. Code is law, but we can always turn off the machines and decide to work on new code and a new law and that new code can become more valuable. Value is just faith.

A fork has been proven as a valid Exit option for disenfranchised community members that feel they have no voice. But I don’t believe fork as governance is something to be cheered and seen as a reason not to work on tools that empower and give voice to your own community

Were these lessons valuable? Definitely. Could we have learned them by other ways? Probably. Was the stress, the distractions, the change in culture, the community split worth the cost of learning them? I don’t think so anymore.

1. be a good game first

2. explore what makes blockchain unique

3. design around the limitations

4. persistent always on world

5. players own the game, the items and experiences

6. allow anyone to design and improve the game

7. embrace bots

1) be a good game first

I see too often people just trying to make yet another skin for a cassino or trading card games. Reminds me of slot machine games, all uniquely identical

2) embrace what makes blockchain unique

Don’t try to make a shooter or something that requires speed. Think about what sort of experience you can create that you couldn’t in any other platform

3) design around the limitations

Only have few moves per second? Then make it strategic turns. Can’t have secret information? Make a commit reveal scheme as part of the game. Moves are expensive? Figure out what actually needs consensus. Need unexplored regions? PoW maps.

4) persistent worlds

Your game doesn’t have multiple servers and will still exist even after you stop developing it. Explore that. Make that communities live and grow on it

5) players own the game

Don’t make a game just so that the users buy stuff from you. Make it so that users own many aspects of the game. They own the land, they own the equipment they own the experience. At some point they should have as much or more control than you.

6) allow others to design

You don’t need to design everything, if you make a great platform others can expand it. Allow them to create new monsters or levels, leave room for someone to update the graphics or make a new expansion.

7) embrace bots

AI is your friend not the enemy. Allow players to build bots, allow bots to be players under the same rules. Maybe coding bots and freeing them on the world might be the most fun

And a final one: use money to reward. A good blockchain game, imho should be one that for most users costs a small price to play but rewards the top players or those who create the best content. But you play because it’s fun, most of all.

I did not start this intending to write a little trilogy on the Parity Multisig hack and its efforts to recover it: I do however care a lot about the integrity of the ethereum community and I wanted to make an alert on the dangers related to a controversial split, and then I wanted to explore a more general opportunity to use the future reduction in ether issuance to deal with this and other similar issues in the future. Now I want to explore another idea that emerged from the last two ones on how to prevent a chain split. Here are my starting premises:

• Community splits are bad and should be avoided

• If a major client gives users the option to fork, then the end result will not be a popular vote but a split

• On the other hand, shutting the door on an influential party that is requesting a fork might just force them to a fork

Incentives for Parity splitting: new ether

It’s a simple calculation really: let’s suppose the overall ethereum community decides not move forward with EIP999, but Parity implements it anyway on their very popular client. The probable result is that there will be a new blockchain, let’s call it Ethereum-999 (should we call it the under-millennial?), where over 500,000 ether that were previously stuck on Multisig contracts can now be accessed. How much will ether-999 be sold for? Cryptocurrencies are volatile and hard to price using traditional means so here I’ll use a simple model: the price of a fork is the likelyhood of that fork overtaking the original chain. Using that logic, at the moment of this writing, the market evaluates Bitcoin Cash having a 15% chance of overtaking bitcoin, Ethereum Classic having 3% chance of overtaking the main Ethereum chain and Bitcoin Gold (lol) having 0.9% chance of being taken seriously by anyone.

It’s hard to know what the market will bet on ether-999 but if Parity puts their development force behind it (even more in the unlikely event that they stop supporting the main chain) then it will be larger than 0, which is what they get for not splitting. A small percentage of access to $250 million dollars is still a lot of money.

Incentives for not splitting: new token

An obvious solution then would be to create a new token, called ether-recovery, and distribute it to all the parties affected by the multisig hack (and other categories of stuck ether). If the potential value of that new ether is larger than the potential value of a split (minus any losses associated with initiating a split) then a fork can be avoided. But what would give value to the new token?

Futures market for recovery

Let’s assume we create tokens for all classes of lost and stuck ether. Before tokens can be created these conditions would need to apply:

• It’s not a recurring event: prevention is always better than recovery, so before a new token class is created it should be show that steps have been taken, either on protocol or in the UX of clients, to avoid these mistakes from happening in the future, as well as showing that if such events are still happening, they are in a much smaller scale.

• Ether is provably not in circulation: having your ether stolen by a third party or claiming you lost the hard drive in the trash would not apply, ether needs to be provably lost forever.

• Ownership can be cryptographically verified in an automated way: it should be possible to run a script and verify which key or keys had access to that ether. So while each token class is dealt in a case by case scenario, who gets assigned tokens in each case can be determined automatically without resorting to lawyers and judges.

After a token class is created, and the lost ether is assigned on a 1:1 basis, then the new token is set to be the children of a recovery contract that will hold any funds gathered towards that recovery. The contract keeps track of its own total ether balance and the sum of the supply of all tokens that are underneath it. Token holders can decide at any point “withdraw” from the account, at which point the following things happen:

• Upon withdrawal, you get sent ether equivalent to the (amount of tokens you own) * (total balance of recovery account) / (total supply of recovery tokens). Meaning that if you own 0.01% of the recovery tokens, you get 0.01% of all ether on that account

• The token is burnt and you are therefore forfeiting all future claims on recovery. Each new withdrawal therefore increases the portion of the pie of the current holders in any future recovery process.

If any fork is attempted that tries to remedy the given class of lost ether, then that token is immediately disconnected from the main contract, even if the fork fails to have meaningful traction (with some checks and balances to prevent low-effort forks just to disconnect tokens).

Source of recovery funds

When receiveing a recovery token, all owners are implicitly accepting a social contract in which all recovery efforts will help fund the main contract. These can be many:

• Donations: this might be a hard sell as many of the affected parties are not people in humanitarian crisis, but often corporations or people are otherwise in a comfortable situation. But given that not forking is a benefit for all, some people or institutions might make a gesture of good will to try to avoid the split

• EIP1015: when ethereum changes from PoW to PoS, the block reward can be significantly reduced to reflect the lower cost of Casper security. Instead of throwing the difference away this EIP proposes a platform to decide, via a smart contract, worthy recipients of the block reward to various uses. If the community votes so, then funding recovery could be one of them.

• Services: a large amount of the funds gathered in the multisig where ICOs, for Musiconomy and Polkadot, for instance. Donating to the recovery fund could in itself create a new token that affected parties could provide some service to.

• Future Insurance of Contracts: we will explore this in the next section

An important aspect is that all these options don’t need to happen in order for the token to have value: the value of the recovery token will reflect the chances that any of these will work at any point in the future. For example, in order to have a portion of the block rewards to be used towards recovery, these actions would all need to happen: Casper becomes ready for deployment, EIP1015 is approved and implemented AND enough signalling contracts vote for this particular use of rewards (and still, it can be a small amount or not last for very long).

A recovery token is unlikely ever to reach a 1 ether parity, but that doesn’t matter: as long as the recovery token is worth potentially more than a possible minority split, then the rational economic choice of all affected actors will be not to fork. And since both can be seen as indicators of chance, the market will be comparing the chance of a minority fork overtaking the main chain, versus the chance of a total recovery of funds via the token.

Future Insurance on contracts

You might be unconvinced that donations would compensate for the immense losses or doubt the viability of implementing other recovery options using future hard forks that are less controversial. You might even be in the camp that people should have to pay for their own mistakes (or mistakes from entities they trusted) and that we should focus on the future. This section is for you.

This recovery contract is meant for ether that has already been lost, but what about future lost tokens? If they are added to the recovery token side, they risk just further dilluting an already very poor pie and could be another governance nightmare. Unless we turn this on a potential profitable venture: staking ether as insurance.

In order to create a new class of possible recoverable tokens these would be the steps:

• Describe exactly what class of contract or application would be covered by the token

• Lock up ether for a predetermined period of years

• One recover-ether is issued for each ether locked up (independently on how many ethers are on the affected contracts)

• The issuer can then sell their recovery-ether for their clients, ICO participants, users or whoever he wants to use the guarantee

• If the ether in the described scenario happens, then the recovery process is activated and the ether is redeemed at 90% rate (the remainder 10% goes to the general insurance fund of all tokens and the victim gets an equivalent amount of new recover token)

• If nothing happens after the given amount of years, then the recover-ether tokens are destroyed and the issuer can have their locked ether back (and keep the profits of the sale)

• If the clients want a continuing insurance after the years passed, then they can go back to step 1

Governance decisions, like which token to accept or not, as well as judging decisions on either a given scenario fits the description of “lost” ether, will all be done via some sort of delegated vote by all the holders of current recover-ether. This aligns the interests of all the potential victims of loss with the profit of the fund as a whole: if the fund stops accepting new applicants or refusing to help an insured party when it needs, then it will affect negatively the future profit of the funds and therefore affect the chances of all parties to be fully restored.

This scheme basically transforms the previous “victims” of lost ether into “shareholders” of a general smart contract insurance fund. But why would someone want to start an insurance fund with over 500 thousand ether in “liabilities” instead of doing just a “traditional” ICO? Because the affected parties of those contracts (which goes beyond the parity multisig and a lot of early users of ethereum) comprises of many of the most technically capable developers (including one of the ethereum founders) and a diverse set of early ethereum users, a captive audience that would help create a network effect that many other new startups would kill (or better airdrop) for. And if the insurance system is seen as having great future potential, it becomes possible that a recover ether to be traded at higher than 1 ether.

In one action we could:

• Give people who participated in this experiment of keeping billions of dollars in beta software a way to recover value lost in errors that often were not their own fault

• Avoid creating a controversial hard fork that can ultimately lead to a split community and a lot of crazy effects on the current running projects.

• Start an insurance fund that allows future contracts also to be safeguarded against eventual failures

• Profit while doing good

Parity has recently proposed an EIP to recover funds lost on the accidental destruction of a multisig library, which held hundreds of millions of dollars at current value by multiple teams. There are many debates rehashing the same arguments of the DAO hard fork, about immutability, precedent and moral hazards. I’d like to present a new side by talking what has changed between now and 2016 in the ethereum platform: a lot of new tokens and a new understanding about forks.

If you build it, they will split it

The first, most important is that forks are not only possible but can be profitable. Saying this now might be obvious, but there were many people who believed, back in 2016 that once a chain split, one of the sides would eventually die out, as economic and social incentives were worked against coexistence. Actually the opposite happened:

• Coin media sites have an incentive to discuss any new fork of a coin, as long as it has any sort of narrative behind it on why it makes more sense

• Even if someone doesn’t believe in the narrative, if they believe that someone will believe it enough to buy it allows speculation (specially if you already had the coin for free)

• There’s an incentive for smaller exchanges to be the first to list a controversial new coin as it attract users and more fee

• mining cost will always adjust to profitability eventually (in ethereum classic it happened in a matter of days)

• The smaller the coin is, the higher upside potential to speculators. If you model two coins as prediction market on which will succeed, the main coin dropping from 99.5% of certainity to 95% might be a slight drop, but it’s a 10x increase in price for those who invested in the small fork

• These early speculators can use their gains to fund development and bootstrap a community that therefore can become self-sustainable

• When forks can’t sustain a narrative or a community, they can still be used by scammers that can use a very iliquid market to manipulate market caps and lead users to compromised versions of the main tools to steal private keys

The main point being: the same censorship resistance, antifragile and self-bootstraping properties of blockchains in general that were able to get most cryptocurrencies off the ground and sustain them long term, apply to any chain splits, making forking a highly profitable venture. As long as you can have any reasonable narrative behind both forks, giving the option to chain split will inevitably lead to a chain split.

Ethereum in 2016 was an experiment, in 2018 it’s a platform

The rules in the previous section applies to all coin forks, be it Monero, Bitcoin or Ethereum, but usually a fork only applies to the coin itself and only matters for very few traders. But with ethereum, there’s a crucial difference: Ethereum is a platform of a thousand tokens. When the DAO raised a hundred million dollars in ether, that was seen as high milestone for crowdsales. But since then, hundreds, maybe thousands of ICOs were built in Ethereum, capitalizing that trend. In the case of another Ethereum Split, like Ethereum Classic, then every single one of these tokens (and apps) will also have their own forks to deal with. What happens to them? Let’s break them in categories.

Tokens as future promises

Many tokens created out of ICO’s have very little built-in functionality and are worth a promise: it will be used in a service or product yet to be built. In these cases, once two tokens exist, the developers will be forced to take a stand and say what they will do. It might be as simple as a blog post clarifying which chain they’ll fulfill their obligation on, but it might also have to involve some sort of community vote or debate. Either way, they will be forced to take a clear position on a debate that they might have no interest in participating and see themselves be dragged in a hot political debate. For small teams it can be a terrible distraction from their main goal, and for some larger projects might involve lawyers.

Tokens are asset custody

Many projects in Ethereum are meant to be backed by something in the real world: gold, oil, real estate. They can be a simple promise by a central company, an so it’s treated like any promise token, but often these projects (or at least the good ones) try to give further guarantees to the user that takes a bit the centralization risk. After all, a token backed by precious metal isn’t worth much if the company that holds them is seized by the government or simply disappears out of thin air. But in the case of a chain split, from the point of view of the minority chain, the token will behave as if the company simply decided not to make good on their promises. How exactly this behaves will depend completely on the legal framework and the tech stack that the organization created to defend itself — and it doesn’t matter which argument the company uses to choose a chain, it’s guaranteed that someone unhappy with the decision, or just wanting to try their luck at doubling their gold reserves, will want to test it out.

Tokens as smart contracts

Tokens that have a more complex contract behind them that decides how they behave are few, but these are also the ones most valuable and best fit to the ethereum ecossystem. A prime example would be the DAI token which uses a complex CFD enforced by smart contracts to guarantee a constant value at $1. In order to do that it uses ether as a collateral and the MakerDAO tokens for last resort valuations and governance. If a chain split occurred, what happens to the Dai holders, do they have now twice the amount of dollars? Since it’s entirely possible to build DAI in Ethereum Classic, if the system works perfectly it’s plausible that the peg would hold in both sides, but at the cost of the collateral owners.

The first things to fail on the Dai would probably be the oracles that input the current price of ether in dollars, used as a basis. Multiple oracle sources are used and they can be updated by MKR holders (more precisely holders of the split MKR token) in case one of them malfunctions, but it’s a process that by design requires time and in this case all of them would stop working at the same time. If the oracles keep working, then the system would work as if there was a sudden sharp drop in ether price, and dai will be burned in exchange for the remaining collateral. If the drop continues, new maker dao split tokens will be issued as a lender of last resort. Maker is working on a DAI that is collateralized by multiple ERC20 tokens: in the case of a chain split, suddenly some of these would be valid and some not, making the situation worse.

Best case scenario the system would stabilize back, with most of the DAI holders being made whole but the CFD creators having lost their collaterals on the minority chain and the MKR holders being extremely diluted out. The technology would be seen as solid, but it would be like testing aircraft safety by removing both engines of a fully loaded passenger jet mid air.

Dapps and games

Ethereum is more than tokens of course, it’s also a platform for apps, games and other sorts of experiments, and all of them would also be split in a similar way. If you are playing a board game, then you’d suddenly be playing two identical games concurrently, and would have to keep playing both or forfeit the winnings in one of the chain. If you own rare online cats, now every one of them will have an evil twin in a parallel universe. Similar things would happen to IOT devices, or smart oracles using embedded chips.

And in every single one of these cases, developers would be asked to support both chains, and in every one of them a smaller version of the same arguments of which chain was the “best” one would be rehashed. Exchanges are an even worse case, because they will suddenly have twice the amount of tokens to support and then they have to figure out which ones are valid in each chain.

Conclusion: splits are bad

Imagine if Google employees could vote on some political stance and then every single android developer would also have to explicitly take an action agreeing or disagreeing. No developer gets into a platform looking for uncertainty, extra support work or having legal troubles for their app with issues on the underlying technology.

During the past years since the DAO hack we learned two important lessons:

• When a controversial fork is proposed, then the end result is not a vote but a split.

• As long there’s a sustaining narrative, both chains will coexist for a long time

• Splits happen not only to the underlying token but to all projects built on top of it

I sympathize with all the affected parties by the Parity multisig wallet disaster that got their funds locked, just like I sympathize with the many projects that had their ether stolen (some also due to another parity bug). I also believe when they say the web3 foundation (the largest invested party) is a serious organization bounded by their mission and the Swiss law to invest their funds in research and decentralized tech. But I think for the sake of the platform, it’s not fair to create a burden on every token. I believe the way to move forward is to build not only better contracts but also insurance systems to hedge against eventual failures and to create a (voluntary) fund to minimize the damages to victims of these failures. Chain splits are bound to happen eventually, but they should be only risked when the whole ecossytem is at risk or needs some sort of upgrade.

The cost of forking might be to create and fund and adversarial community, as if a parallel universe collided and out of there jumped an alternate version of you with a goatee, whose mission is remind you of all the potentially bad decisions you took, and to prove they are worthier than you.

Let’s avoid invoking our evil twins.

Both coins share some long common friendship. When Ethereum was running its presale, doge was at the top of the game, sponsoring race cars and overall having a lot of fun. I think it was the first coin to really get that a community, not only tech, was the most important thing.

The ethereum community was formed, in part from people that didn't like the bitterness that overtook Bitcoin, so we always tried to be light hearted and fun. Devcons accepted dogecoin. I mean, look at this guy, does he want you to take him seriously?

Doge was excited about ethereum too and they posted a thread asking if it was possible to be integrated in ethereum.

So a few days later, "some guy" had implemented Scrypt (doge's native code) in Ethereum.

Caveat: it would cost about 370M gas just to do one single header verification. But maybe someone could find a solution to it, and some people they could do it, so I implemented a DAO that would hold a bounty for that purpose and asked donations.

Many donations came from both doge and ethereum community. Someone donated 5 thousand dollars, other people donated just a few cents. The bounty quickly grew to.. well mostly to a bit more than 5 thousand dollars. Yeah, mostly from that one donor.

The problem was, that verifying a single doge transaction would not fit in the amount of calculations afforded per block. They could be broken down in steps, but they would still be super expensive. That's when @ethchris (the father of solidity came up with a very clever idea:

Going to court is expensive, but not all written contracts need lawyers and judges: but knowing that you can if needed, means both parties tend to behave. You can do the calculation off chain, put money on answer and only calculate if there's a dispute. @Truebitprotocol was born.

In the mean time, some developers have all approached the judges and said they wanted to work on it. Seemed like a quick and easy job. It wasn't. So the bounty stayed frozen, while ether price rose. The original big donor even asked for his money back, so we gave it to them.

Still, at some point the bounty passed a million dollars. That should get some attention to it. And it got.

@oscarguindzberg, @coinfabrik and @Truebitprotocol got together and worked for many months on it and finally had something to show for it.

Now it's only one-way now, and it's not production ready but let me recap what these crazy people demonstrated us:

They built a DOGECOIN LIGHT CLIENT ON ETHEREUM. A contract that can check what is the latest dogecoin block, calculate proof of work, figure out chain splits, etc

Right now it can verify that a transaction was sent in Dogecoins to a given address and generate the same amount of cute shiba inu puppy gifs in an ERC20 token. Still need some work to make it solid, then more work making sure they can come back as doge coins, etc

Still, as a judge I believe the work demonstrated merits 25% of the total bounty, which is 372 ether which is worth $350k.. wait $299k.. or maybe $310.. Whatever.

What can you do? You can check their work yourself by following the above links and also reading up on this.

If you have any concerns, opinions or suggestions about the first award, please let the judges know. They have a week to vote and debate.

Also the remainder 75% of the bounty are still open. That team will still be working to make the app better, but our desire is to see an easy to use interface that anyone can build, so even if you are a simple web designer good at gifs, you can apply to help.

Venezuela released a white paper.

And it’s sooo good.

First of all it was inspired by Chavez, the first person in history to think that currencies should be backed by things. Screw capitalist pig Satoshi, Chavez basically invented crypto. I mean really crypto: Diffie-Helman plagiarized him. He probably invented all currencies too.

It’s super innovative. Can you imagine the consequences if the Venezuelan people had access to a currency that could be used for investment, savings or means of exchange? Why didn’t anyone think of this before?

‘The Venezuelan state will not be able to make new emissions”. Except the “superintendency of currency of Venezuela” reserves the right to activate new features, like PoS emission. Or maybe PoW. Which it doesn’t need.

But it’s totally not the government.

The supply is limited, the demand is market based, but the price will be somehow pegged to the price of oil. Because, thanks to socialism magic, price is not set by supply and demand, but by this incredible formula where both Petro and the Bolivar are divided by themselves

Notice that in the formula above, not only the “discount rate” DV is set by the government, but the price of Petro and Bolivar as well, as it’s calculated on “exchanges authorized by the government”

The ICO will happen the day after the day after the pre-sale closes. And tokens on the ICO will be generated by burning the pre-sale tokens. For reasons. And both will have multiple phases. For reasons.

And it doesn’t accept Bolivars. For obvious reasons.

It’s a token on ethereum, which doesn’t need mining. But it might also be mined anyway in proof of stake. Or maybe they reserve the right to make it proof of work. And miners will be paid in Petro, which is based on price of oil which has no correlation to miner or security cost.

The government cannot create Petros (but it can) which in theory should make the market happy, but there’s no mechanism to issue or destroy the tokens, it’s basically impossible for it to do the one thing it’s supposed to do, follow the price of oil.

So it’s “backed by Venezuelan oil” in the sense that Venezuela promises to buy it back at a discount rate (that they decide) on the price of exchanges (that they control).

But the strength of the Bolivar is a great proof on how much the people trust the government promises.

I am not going to say that the Petro is a useless token intent to get ether and bitcoin out hands of dumb greedy people and in the hands of corrupt government officials, because it has a very clear use:

To circumvent the international sanctions put in the Venezuelan regime.

So there you have it. If you were desperately looking to gamble some money while at the same time funding oppression and probably running amok of international finance laws, then I have just the perfect token for you.

Bitcoin price fell from 600 to 300 just after the presale, before we could touch most of it so right there half of the money we had raised was gone. The other half was spent developing the clients and launching the network, by August.

The network was live, but we still needed years of development and the money was running out. We had ether, but it was still under $1. They asked Geth devs (and therefore Mist) to take a 10% haircut, mgmt took more. CPP team was almost all cut out. Everyone was feeling down.

Back then, many still thought ethereum was a scam/vaporware and never going to launch. We proved them wrong. But as local saying, we had swimmed, swimmed and were about to die on the beach.

Then, by the end of 2015, things started turning around. The multiple entities were closed and our haircuts were buying us time. Ming spent most of her time cleaning up an excessive and expensive legal infrastructure and going through audits and hell of paperwork.

Then Devcon 1 came around (Devcon 0 was a internal developers only get together in Berlin), and Microsoft was a sponsor, Nick Szabo was giving a keynote, it was a clear message that the industry took us seriously.

This was followed by the price, which passed $10 and felt like crazy. Suddenly we had a longer runway and everyone could breathe again. There was and still is a lot of work ahead of us...

But probably none of that would have happened had @mingchan88 not stepped in her role. She was never in the forefront, had no public face other than a few words before Devcon. But on the inside she was crucial, and she worked through multiple Christmas, Thanksgiving and New Years

The Ethereum Foundation is far from perfect, of course. We can do a lot to be more open and transparent, and to act less like a raunchy startup but the leadership of a $200 bilion ecosystem. But to get here, a lot of people had to do big sacrifices that went unthanked.

Not anymore.

Thanks Ming. I’ll miss our two hour skype calls about the history of China and your tales about Media Lab. You deserve some rest and family time.

(History from memory, dates and details might be slightly wrong)

Contract standards are one of the most important thing in ethereum: the reason so many projects can issue a token that can be used in other wallets, or exchanged via decentralized exchanges or really used for anything else, is that they all use a set of same standards, basically a "balanceOf" call that tells you how many tokens you have and a "transfer" function that tells you to transfer these tokens from me to you.

Token standard has been one of the first proposed standards and were talked about and debated by multiple users until finally formally written down by /u/feindura/ which also implemented it in Ethereum Wallet, first wallet to adopt it.

What are the main issues with the current ERC20? Many. The first glaring one is how to transfer tokens to contracts. Because you can send tokens to any ethereum address, you can easily also send them to contracts which do not support them, locking them forever. Worse than that: even if the tokens can be manually moved, it's very hard to tell which tokens came from who, and try sending them back.

To solve that, the ERC20 used to have a approve function that would allow you to approve the transfer to a contract and then you needed to create a second transaction, letting the contract know you had approved it. This required two transactions, had multiple security issues and was not widely implemented.

Multiple token standard have been proposed since ERC20, to solve that famously ERC223 and the "aproveAndCall" standards. Others have been tried to augment the functionality of tokens by allowing off chain signing to transfer without needing ether, or private transfers that use zksnarks or ring signatures to add privacy to tokens. None had much momentum, but ERC777 seems to be getting it, because it implememts all in a more elegant way:

ethereum/EIPs#777

Backwards compatible

Making your token ERC777 compatible will make it compatible with more important functions of ERC20 (and you can implement the rest and make it fully compatible)

Safer and simpler send to contract

Introduces a new transfer function that adds a third field called bytes where you can add any identifying information to the transfer and it automatically lets the receiving contract that the transfer occurred, so it can do something automatically

Sets decimals to default 18

This a controversial move: many people feel that it was a mistake to add custom decimals to ERC20. The idea being that its not very useful to add lower limits on the divisibly of your token (and it doesn't make sense to add more thann 18) and adding custom decimals make writing offline wallets like Trezor, harder. ERC777 doesn't remove the decimals, but defaults it to 18.

Adds Approved Operators

The idea is that you give a contract the right to move tokens in your behalf, which means that you can build contracts that enhance your token, independent of the token needing to implement it. Want to add anonymity? Authorize a mixer contract as an approved operator. Worried about backups? Add an emergency recovery service that can move all your tokens out if you lose your keys. People can improve your tokens, years after they were created. This allows the contract full access to the contracts, so any sort of limitation (like daily limits based on exchange rate) needs to be built in the token itself.

What else?

The standard is not finalized, and that's where you come in. Make your opinion known, what do you like or dislike about it? What would you want changed differently? Next time you meet someone building a new token, ask them about their opinion on this standard.

‹1 / 34›

So I planned my paternity leave to coincide with our 39th week but my daughter only came at 41 weeks and 3 days, giving us plenty of unplanned free time, so I tried to make a page per day during that period.

I wanted to cover Daenerys story in season 1, but adapt it to a kid friendly format and with a empowering message for my daughter, so I decided to take as many liberties as the average Disney movie takes with their original content, which is to say, a lot.

So I really removed most of the plot elements and it’s a story about a princess who really wants to be a queen, meets a bunch of weird people who give her lots of bad advices, underestimate her and say how it’s impossible for her to be queen. In the end she decides to do things her own way and makes herself queen of the dragons.

EIP 98: Removal of intermediate state roots from receipts (#14750).

This allows more parallelization on transaction processing, as not all transactions require the result of the previous one.

Expanded by EIP 658: Embedding transaction return data in receipts (#15014).

This allows light clients to be able to see if a call they made was executed properly or if it failed. This could only be verified by full nodes previously.

EIP 100: Change difficulty adjustment to target mean block time including uncles (#14733).

In bitcoin, only miners who found a block and sucessfully added it to the main chain received block rewards. This leads some ineffiency and some miner centralization as miners who were physically close had an advantadge and wasted work so Ethereum created the uncle reward, in which if you found a correct block but it lost the race to reach all other miners, you would still get paid. But this led to an error in which the total issuance was slightly higher than the expected 5 ether per block in an unpredictable way: during moments where internet connectivity lagged or the network was too busy, more uncles would mean more ether was created. This EIP fixes that.

EIP 198, EIP 212 (197) and EIP 213 (196): Precompiled contracts for modular exponentiation; elliptic curve addition, scalar multiplication and pairing (#14959, #14993).

Adds some cryptographic primitives that enable some new use cases, mostly around zk-snarks. This indirectly enables new novel uses, including higher privacy, scalability and other stuff people will come up with.

EIP 214 (116): Expanding the EVM with static contract calls (#14978).

Whenever a contract calls another contract in the middle of their function, that contract takes priority and can then do anything it wants, including calling the original contract back. This creates some complicated situations that makes writing smart contract more complex as there are tons of ways in which your contract state might have changed after that call in which you can't predict (The Dao bug, for instance). This creates a safer way to call an unknown contract from inside your contract.

EIP 211: Expanding the EVM with dynamically sized return data (#14981).

explanation from /u/izqui9 At the moment when you make a call to another contract you must specify how many bytes of return data will be copied. EIP 211 introduces two new opcodes RETURNDATASIZE and RETURNDATACOPY. After making a call you can check how many bytes the call returned and then copy exactly that many bytes. This is specially exciting as it will enable Forwarding contracts to return exactly what the underlying call returned. Right now Forwarding contracts rely on hardcoding how much memory they will read from the call, but this is not a good solution for dynamic sized types such as strings or bytes array that can have an arbitrary size.

EIP 206 (140): Expanding the EVM with cheap state revertals (#14983).

In almost any contract you usually want to check multiple situations that would prevent a transaction from being executed: maybe the caller is not authorized to do that transaction (not the owner!) or maybe the contract is not yet on a state in which it can do that (crowdsale has not started) or some other limit (participation cap is reached!). When that happens you want all execution to stop and no state to change so you execute a throw function. The issue is that is an expensive call: it burns all the gas sent and doesn't provide the user any way to tell the reason it failed. This introduces a better way to do it: by using revert instead of throw, you only spend the gas the user actually used, and it provides a useful error code telling the user why their transaction failed. Super useful for app development!

EIP 649: Delaying the difficulty bomb and reducing the block reward (#15028).

Self explanatory: delays the iceage by 18 extra months and reduces block reward to 3 ether in preparation for future PoS reduction.

EIP 684: Preventing overwriting contracts (Byzantium prep) (#15039).

Byzantium will change the way in which contract addresses are created. This prepares to prevent collisions, by preventing contracts from being deployed where there's another one existing.

Censorship resistance: This isn’t a property of blockchains, but of information online. Once that shameful picture of you leaks online, it can live in personal hard disks, it can live in burned cds, it can live in small obscure corners of the globe. What we really need is a change in attitude: stop shaming people for their sexuality, past behavior and substance abuse. Understand that by sharing a picture of someone being bullied or hummiliated, you are also helping the hummiliation. Forgive people for their past mistakes. This isn’t a tech challenge, but a social one.

Financial Freedom: It’s true, privacy can help hide corrupt acts and laundering of money. But does giving extraordinary powers of omniscience to the powerful actually help prevent that crime? Or does it simply empowers them as they can use their influence to selectively police some transactions but not others? It’s my opinion that the past decades have proven that this has been the more likely outcome: the rich and powerful will always find ways to launder their money. What can we do to prevent this? By taking their power away. Where does that bribe money comes from? A large part comes from money collected in taxes that should fund health and education is instead siphoned away into corruption, mostly because of a total lack of transparent accounting in governments. So I believe the way to fight corruption is at the source: make governments radically transparent, make so that governmental programs are automated with blockchains, tools that blockchain enable.

Tax Evasion: Common mistake that financial privacy means governments can’t collect taxes anymore. For the longest part of the last many thousand years of the history of taxation, money was untraceable (gold, stones, etc) and taxes were collected anyway, it’s only for the past 50 years or so that govenrments started to having omnicient power over their citizens finance, and we already believe they would crumble? The good news is that blockchains allow taxes to be automatically collected. Most of the stuff that government deals with is basically databases (property, identity, etc) and we can automate those taxes. Vlad and me both attended a london workshop about ENS where the consensus was to create some sort of “tax” on domains to make sure the owners would optimize their utility: here’s an example of a voluntary, non-violent system that allows taxes to be deducted and that deals automatically with those who don’t pay, by auctioning off the domains after a year.

Evil DAOs: if evil decentralized organizations are able to outcompete evil centralized organizations, then it’s true that there will be many of them, and they will likely take over as they drain the profit out of traditional mafias (as evil DAOs don’t spend money on yatches and prostitutes, only on their own growth). But if this happens, it also means that the concept of DAOs are so successful that they apply to all society, and that most of what we think of the way we are organized will be disrupted. It means that policing, investigating and combating the evil daos can also be automated. I have no idea what the result will be, but it will interesting to watch.

Saiu o resultado da última eleição e você provavelmente está focado no que aconteceu no Executivo. Mas essa eleição, foi acaba de ser definida sua nova câmara municipal, que deveria ter um impacto grande no que acontece na sua cidade. E agora, você sabe quem te representa na câmara?

Se o vereador que você votou foi eleito, parabéns, você está em uma minoria! Mas se você precisar que ele ou ela te represente em alguma coisa, você tem acesso ou a pessoa é popular e inalcançável demais pra isso?

Se seu candidato não foi eleito, a pergunta fica mais complicada: você é representado pelo colega dele de partido? Ou talvez alguém que mora perto de você mas você não votou? E os políticos que ganharam suas cadeiras por voto do partido, a quem eles representam? Quem é responsável por fiscaliza-los?

Ou será que nessa câmara completamente renovada que nem começou a trabalhar, já vale o clichê:

Nenhum desses políticos me representa

Sendo tão difícil assim responder a essas perguntas simples, não é de se espantar que estejamos vivendo em uma crise de representatividade onde grande parte da população se questiona pra que sequer temos tantos desses políticos.

Não há nenhuma razão dessa distância tão grande entre políticos e os seus eleitores. No Brasil, um município pequeno tem 1 vereador para cada 500 pessoas, podendo chegar até 1 para 150 mil nas grandes capitais. Parece um número grande mas se você conhece 500 pessoas pelo primeiro nome, e cada uma dessas pessoas puder te apresentar 500 outras, significa que você está a um aperto de mão de distância de 250 mil brasileiros. Mas vereadores e deputados no Brasil são tratados como seres de outro mundo, sub celebridades distantes e inalcançáveis, não um amigo de um amigo.

Pra piorar a situação, durante o período da eleição existem centenas de pretendentes a cada vaga, tornando impossível ao eleitor conhecer a todos, reduziondo-os a números de cinco dígitos (quatro para deputados federais) a serem memorizados. O Brasil tem dez vezes mais prefeitos que deputados, mas enquanto os eleitores minimamente informados conhecem seus candidatos a prefeito, assistem debates e discutem com amigos as opções, quando chega a hora de escolher um representante do legislativo, não existe nada disso. Em geral os eleitores vão em indicação de amigo, rostos conhecidos ou gente que chame a atenção de outra forma. É assim que o sistema estimula que sejam eleitos velhos políticos, celebridades decadentes e palhaços.

Não falo de “sistema” de forma genérica, mas especificamente do nosso sistema de contagem de votos, chamado de voto proporcional. Seu voto é computado entre todos os outros eleitores e depois redistribuído de acordo com uma série de regras complexas e opacas cujo objetivo é fazer com que os partidos tenham uma distribuição de cadeiras proporcionais aos votos recebidos. Esse sistema foi criado para substituir o sistema distrital, ainda usado em alguns países como Estados Unidos, França e Inglaterra onde os eleitores são divididos em áreas geográficas menores e o mais votado de cada distrito é enviado para a câmara.

Em um voto distrital, a fronteira dos distritos e distribuição dos eleitores influencia completamente uma eleição. Dois partidos com a mesma quantidade de votos podem ou tomar controle do congresso ou não ter nenhuma cadeira, dependendo de sua distribuição geográfica(vide abaixo). Essas distorções forçam o eleitor a pensar mais no “voto útil” e não votar em partidos menores que ele prefere. Quando se dificulta que novos partidos possam crescer a renovação política se torna muito mais difícil.

O voto proporcional foi feito para resolver esses problemas mas com ele perdemos a maior vantagem do voto distrital: a relação direta, geográfica, entre o representante e o representado. Em uma eleição distrital, todos sabem quem são seus representantes, e os políticos sabem quem está lá cobrando deles. Além disso, a proximidade geográfica torna mais fácil implementar um recall em caso de escândalo, diminui os gastos de campanhas e faz com que o político seja literalmente vizinho do seu eleitor.

Será possível ter o melhor dos dois mundos?

Sim. Alguns países como Alemanha e Nova Zelândia, usam um sistema misto. Normalmente esses sistemas são mais complexos para o eleitor, envolvendo um segundo voto e listas elaboradas pelo partido. Aqui descreveremos um método muito mais simples, que faz esses cálculos de uma vez. E de brinde, podemos diminuir até a metade a quantidade de políticos.

Eleição distrital com repescagem

Imagine que o Brasil seja dividido em distritos eleitorais de de acordo com sua população. No caso de um deputado federal, cada distrito teria 600 mil habitantes (uma cidade média ou uma zona de uma cidade grande) e no caso de municípios o número iria variar até 250 mil (um bairro populoso) em grandes capitais.

Partidos poderiam lançar apenas um candidato por distrito. Para o eleitor isso significaria o fim de memorizar longos dígitos para cada candidato: para votar no seu candidato, bastaria digitar o número do partido (um voto em um candidato é considerado um voto no partido). Com um número limitado de candidatos por área, torna-se mais fácil a organização de debates locais entre os candidatos e não haveria a necessidade de caravanas passeando por todo o estado ou cidade, possívelmente diminuindo os custos de campanha.

A eleição se da em apenas um turno, com o candidato mais votado automaticamente ganhando uma vaga na câmara, mas nesse momento apenas metade das cadeiras é distribuída. Ao final dessa eleição distrital simples, compara-se a distribuição de cadeiras com os votos conquistado pelo partido no total. Caso não haja distorções significativas (digamos que as distribuições de cadeiras e votos esteja a menos de 3 pontos percentuais de diferença) a eleição é dada por concluída.

Isso significa que em alguns casos as câmaras teriam apenas metade dos políticos atuais, economizando dos cofres públicos.

Caso contrário começa o processo de repescagem:

A repescagem

Para cada partido, calcula-se a diferença entre a proporção de votos obtidos e cadeiras conquistadas. O partido que estiver mais sub representado (tiver a maior diferença, em pontos percentuais, entre votos populares e composição na camera) ganha automaticamente uma vaga a mais e a preenche com seu candidato mais votado que já não esteja eleito.

Imagine que um partido tenha ganho 120 mil votos dos votos no total de um município de 1 milhão de habitantes mas tenha conquistado a maioria em apenas 1 dos 25 distritos eleitorais. Como ele conquistou apenas 4% das cadeiras mas teve 12% dos votos, ele ganha direito a uma cadeira a mais. Essa vaga não vai para um desconhecido do eleitor, mas para um dos candidatos de outro distrito eleitoral que tenha ido muito bem na sua campanha e provavelmente ficou em segundo ou terceiro lugar. Agora o partido tem 2 vagas das 26 da câmara (7%) e as diferenças entre votos e vagas ganhas são recalculados para todos os partidos novamente.

O processo é repetido até nenhum partido ter uma diferença de representatividade maior do que 5 pontos percentuais entre os votos e as cadeiras, ou até que todas as vagas tenham sido preenchidas.

Vantagens desse método:

• Menos custos: Garante-se que na maior parte das eleições as câmaras ficarão com um tamanho menor ao que temos hoje em dia

• Garantia de proporcionalidade: a câmara sempre terá uma composição semelhante aos votos conquistados no total

• Proximidade geográfica: cada distrito envia um ou dois candidatos, tendo portanto uma conexão direta entre os representantes e seus representados

• Maior cobranças: cada cidadão é responsável por ficar de olho em um ou dois vereadores que ele elegeu, facilitando a implementação de um Recall caso a população deseje.

• Nada de fantasmas: Políticos só são eleitos se tiverem votação significativa no seu próprio distrito.

• Menos ou tudo ou nada: se dois candidatos tem uma eleição apertada, o segundo colocado ainda tem uma chance ganhar uma vaga na repescagem.

• Sem votos desperdiçados: um voto em candidato que não ganhe a eleição pode ajudar um outro candidato do mesmo partido que tenha tido uma votação mais significativa em outro distrito

• Sem puxadores de votos: pela limitação de distritos uma celebridade muito famosa não pode ganhar mais do que 100% dos votos em uma área, e consegue no máximo ajudar a eleger um segundo candidato bem votado em outro distrito

• Campanhas mais baratas: sem necessidade de viagens ou campanhas de alcance nacional, os custos de campanhas são reduzidos

Gostei, mas isso nunca vai ser implementado!

O meu maior objetivo com esse texto não é realmente esperar que um sistema desses será implementado tão cedo no Brasil, mas fazer as pessoas prestarem menos atenção nos políticos corruptos que são eleitos e mais nos sistemas que fazem com que eles sejam eleitos. Não acredito que todos os problemas do Brasil sejam causados por políticos desonestos tentando sabotar o país, mas que muitos problemas são, na verdade causados por resultados esperados de defeitos em sistemas complexos que ninguém está prestando atenção. Então na próxima vez que você estiver frustrado com um político ou uma crise, tente pensar em de quem ou qual partido é a culpa, mas o que poderia mudar na forma como somos governados para que os desonestos tenham menos oportunidades.

Discuta entre seus amigos menos sobre pessoas e mais sobre formas de fazer uma reforma política.

A desesperança na democracia é algo muito perigoso, e a única forma de realmente mudar algo grande é focar em uma parte pequena que poderia melhorar.

This is an attempt of setting up a name registrar that use deposits instead of burning or token contributions and tries to optimize name utility and reduce domain squatting. Previous initiatives of charging a "rent" based on the market price with an yearly auction proved impopular with many developers as they believed the registrar wasn't delivering any value for the "tax" as well as worries that a sudden big auction could force someone unexpectedly to be forced to sell the name.

In order to start doing that let's define the problem:

Name squatting is defined as buying a name and not adding any value to it, just holding it expecting that domains names will become more valuable in the future. Let's assume that all name buyers have the intention of acquiring a name and make it more valuable over time, either by working on it as a business and adding value to the "brand", or by working to increase the chances of finding a better suited buyer, all have variable success on these endeavours. It's natural to assume that the value of new names being acquired should keep in line with the market values expectation of how profitable they are to sell (either as a brand, a business or a placeholder domain) in the future.

The solution here lies to require a deposit to own a name and periodically require the owner to update their deposit to what is assumed to be the market rate of the name of their current name. If names in general have increased in value but the owner is among the bottom half that hasn't done anything to increase the value of their own names, then all possible profit will be negated by the extra deposit. If names have decreased in value the owners can request to withdraw part of the deposit and the cost of the name will be the cost of opportunity of possibly having invested in something that would have a better return. At any point name holders can release and get the full deposit back.

So the process is a nutshell:

Process

1) Start Auction for available name

Anyone can start an auction by sending an array of hashes that they want to bid for. Arrays are sent so that someone can open up an auction for X dummy hashes when they are only really interested in bidding for one. This will increase the cost for an attacker from simply bidding on all new auctions blindly. Dummy auctions that are open but not bid on are closed after a week.

2) One week auction for the desired hash

Bids are sent by sending a message to the main contract with a hash and an amount. The hash contains information about the bid, including the bidded hash, the bid amount, and a random salt. Bids are not tied to any one auction until they are revealed. The value of the bid itself can be maskeraded by changing the required period or sending more than what you are bidding for. This is followed by a 24h reveal period. Bids revealed after this period will be burned and the ether unrecoverable. Since this is an auction, it is expected that most public names, like known domains and common dictionary words, will have multiple bidders pushing the price up. The minimum bid will be set as the equivalent cost of sending 1000 bid transactions, to increase the cost of trying to spam the network with dummy domains.

3) Winning bids are deposited

The highest bid gets control of the name, by depositing the equivalent amount of the second highest bid. The funds will be held on new contract, controlled only by the owner which contains basic information like when the name was first registered, when it needs to be renewed, and the price paid for it. The price paid is also saved on a moving average amount, calculated as averagePrice = averagePrice * 0.999 + newPrice * 0.001. The averagePrice at the moment of purchase is also registered on the contract.

The name registrar itself doesn't need to store any ether. Instead, each name could be itself a contract that is acessible only by the owner or the name registrar contract, reducing the attack vectors and making it impossible for someone to take more out than they originally had put in.

4) Renewals can be done at any moment by renewing the deposit

In order to renew a name you need to calculate how much have average prices of names changed since you last bought it. If the average price names have increased, then you need to increase your deposit. If median prices have fallen down, then you have the right to withdraw part of the difference (1/2 after a year, 3/4 after 2 years, 7/8 after 3 years etc).

required deposit =  cost of name at purchase * latest median price of name / median price at auction or last renewal

This calculation assumes that market values of each particular name are fairly calculated by an open auction, and that the only variable are the demand for new names, the premise being that if the same auction had happened today, this is the amount that you would have to pay for the name. All other variables, like the market price of ether or the perceived demand for names, are thought to be included in each individual auction. Renewals can be done at any moment up to the expiry date.

Once renewed, a new expiry date is set by adding the age of the domain to the current date. Therefore when registered a name needs to be renewed after a year, then after 2 years and then 4 years after that.

Being able to withdraw only partly is made to disincentive users using name holding as proxy for ether holding. This means that liberating the full name is worth more than keeping the name - otherwise owning a 10 ether name would be functionally equivalent to owning 10 ether, with the added benefit of a small chance of reselling it as property later.

5) Names not renewed can be released at any time

The real cost of holding a name is the opportunity cost of doing something better with your ether. If there are better opportunities, like staking it, lending it or investing in some other new venture, then holding names should be seen as an undesirable outcome and owners have an incentive to release them. Names can be sold at any moment, but the buyer will incur the same renewal cost/benefit analysis.

Scenarios

Alice buys alice.eth for her personal use. She bids 2 ether, which is about twice the average most people are paying for a name. One year later, ether is still trading at about the same price, but names became more popular, being bought now at an average of 2 ethers. It means that for her to renew her name, she needs to put an additional 2 ether on the deposit. She makes the calculation that her domain is worth the extra ether, so she is happy to do it.

Bob decides to buy foo.eth because he believes that company Foo will want to buy from him. He imagines that there's a 10% chance of the company buying the name for 100,000. So he bids 10,000 ether and wins, which is way over the average and way over the second place that bid only 1,000 ether. Bob get's 9,000 ether back and keeps the name with the 1,000 deposit. One year later, Bob wasn't able to sell the name, ether now is trading at twice the price, but since demand for names hasn't gone up, they all now go for an average of 0.5 ether. This means that now Bob can withdraw 250 ether and keep the name for another year. But bob realizes that, in dollar averages he would value that name at 500 ether, yet he has 750 ether locked up on that contract. Since Bob hasn't found a better buyer, he decides to release that name, get his full 1,000 ether back and put it to use on something else.

About the same time Bob buys foo.eth, Eve also buys foobar.eth for 100 ether. She believes she has a 10% chance of reselling it for 1,000 so she considers it a bargain. One year later she hasn't sold the name yet and can renew it by withdrawing 25 ether. She keeps 75 ether on the name, althought the deposit value is now worth 50% more than what she originally paid, she has since set up a name selling company and believes her chance of selling that name has also increased, so for her it is still a bargain. Alice keeps the name.

There is a common narrative in some communities that support Ethereum Classic, one in which the Ethereum Foundation is painted as the corrupt bad guys who pushed the fork for financial reasons and the DAO attacker was a liberating hero. A narrative in which the DAO was sloppy code which was obvious to anyone watching that it would crash and burn. A story in which everyone involved was incompetent or unwilling to help.

Those narratives are not only false, but they are are provably, publicly false, yet they persist either because they are easy stories to repeat, or because some of those repeating it are ill-informed or ill-intentioned.

False claim #1: The EF or their members were financially motivated to fork

Many foundation developers (including me) have come forward about their dao holdings. Most (including our Executive director, Ming Chan) have none, some have very small amounts. Many have openly criticized the DAO. Of course, one can argue that we could be lying, or that the big holders are not disclosing but in all internal and private discussions I’ve had within the team, “saving my holdings” was never even brought up. Maybe there’s some shadow figure lurking behind the developers and influencing the foundation’s decision, but they are certainly not among any of the coders I talked to.

Even among those who owned part of the DAO, they had very small amounts, relative to their Ether holdings. Who would, in their right mind, want to risk 99% of your wealth to save 1%?

From my experience, I’ve seen the opposite happening. When the news that a white hacker group needed DAO tokens to try to salvage the remainder of the DAO, most volunteered to donate their own tokens, without knowing if they would be burned in the untested process or even asking the identities of the hackers, just to try to save the DAO.

False claim #2: The Fork came from the foundation against the community wishes

The first client to start working on the Fork was Parity, developed by Ethcore and not affiliated with the EF. The Foundation develops two clients, the C++ (which only started working on a compatible version after the fork) and Geth, which started implementing the Fork late in the game. If anything the go developer team was heavily criticized for taking too long to build and test their code.

It’s true that Vitalik was one of the first to propose a fork, right after the DAO hack, but it was seen as one of many options and not a yet definitive answer. Anyone who participated on any ethereum community during the long 30 days that preceded the fork can attest that this was a highly debated topic. I personally helped built Stake Voice as a Mist App to help measure how much the community actually felt about it. It was based on some code from Ether Signal a forum weighted by ether stake that was being built for the occasion. Carbonvote was created by the Chinese ethereum community and was released a couple days before any of those tools became available and soon became the most popular polling app. While Geth had a default, Mist, and the Ethereum Wallet, the official GUI clients did not choose any and forced users to pick from a randomized window.

Carbonvote was not the sole measure, talking to individuals, companies, outside developers, reddit up votes, twitter polls, any signal we could measure indicated the Fork had a high community support. And it showed on the day of the Fork. We immediately had over 90% of the hashrate and market. The community had a near consensus for this option and the anti-fork group was a minority.

The foundation provided the community a choice they were loudly and repeatedly asking us for.

False claim #3: The DAO issue were entirely the DAO’s creators fault

At launch day, The DAO was lauded as an overwhelming sucess, having being reviewed by the foremost experts in the field, the crowd, and a private security audit. At the day of the hack, it was immediately derided as sloppy coding, hastily built and unreviewed. Notice the difference?

The DAO hack was made possible due to two lines of code in the DAO, where first it sent funds and then it changed the owed balance. It’s true that had these lines being in a different order the hack would not be possible.

But while the first reentrancy behavior was described on an unnoticed blog post in 2014, it was not widely understood until it was rediscovered by the developers of MakerDAO with a similar hack that allowed them to drain their own contract. So the importance of that particular ordering of the code was not known by any of the experts in the field. The hack would not be possible if Solidity, the official language treated nesting differently, or how much gas it would send in the .call() function. The bug would have been discovered if formal verification tools where available, that would allow to mathematically assert some invariants (like that no one could get more than it had).

I’ve seen the bug being compared to SQL injection, an unexpected behavior that at some point affected most web applications, but once it came to the public consciousness of web developers, it was rather trivial to prevent.

So while demise of the largest crowdsale in history was caused by two lines of code on a contract, it was also caused by a series of immature tools in an 8 month old ecosystem, dealing with completely new fields of knowledge.

The biggest mistake in the DAO wasn’t bad code but launching when the platform was still too young and the tools still immature. In hidsight it’s easy to point that many things could have been done to limit the size or scope of the project, but the truth is that nobody expected the DAO to become as big as fast as it became. The DAO was Ethereum’s first viral sensation.

False claim #4: Nothing else was done to prevent the issues

This criticism usually comes in two flavours: that either the curators / developers / slockit didn’t do anything when warned or that they did too much and should never have interfered. As a curator, an ethereum developer and a friend of many involved, I was witness to many of those key moments and can safely say this was not true at all.

The first issues of the DAO were raised by Emir Gün and Vlad Zamfir. The curators responded by following the suggestion of a moratorium and no proposal was approved. After the reentrancy attack was reproduced on MakerDAO, it was soon pointed out that it could be used to attack the DAO reward account (which was empty), leading the Slock.it team to publish the now infamous “No Funds at risk” blog post. Very few people at the time understood the full extent of the bug and therefore no one realized it could be used on the split function until the attack happened. It’s also important to note that even if someone had disclosed it responsibly it’s probable that there would be no way to salvage the DAO. It was already live and holding the funds when the first reentrancy issue was found and the Curators had no power to stop it (curiously, curators where criticised at the time of “having too much power”). Draining the DAO would reveal the issue and trying to upgrade it would take two weeks minimum.

The guys that are often the most vilified on this story are those who lost nights and worked for months without pay to try to salvage the community funds and they are often villified by those who are not taking risks or trying to do anything that has not been done before. In the space of about a month, thousands of new tools were developed to try to salvage what could, white hat attacks, soft forks, blockchain analysis. The Hard Fork was a last ditch effort and everyone tried to keep it as simple as possible because of the small amount of time available (therefore we chose not to deal with replay issues at that moment).

The No-Fork is not the only logically consistent position possible

All the points I raised before were not opinions but simple true facts, to disprove the false narrative that is used to criticize our decisions. You can still take the new narrative and disagree with our decision, but before you do, I’d like to point where the disagreement comes from, as it can surprise you.

I’ve received a lot of criticism for the first phrase on the Ethereum.org home page as the fork would change the “exactly as programmed” promise. I wrote that phrase and still stand by it as I still believe that is the vision. I do not like semantic arguments, and believe the place to argue the definition of words like “bug”, “attacker”, “theft” or “hacker” is on wiktionary.

At the end of the day, what good is to be able to build a contract that will work “exactly as promised” if what it actually does is not what anyone expected? What’s the value of a technology that is intended to build “smart contracts” if not even the top experts in the field can make sure they are either smart or contracts? The DAO was the biggest project that Ethereum ever had, it introduced to thousands of newcomers the very idea of software that manages resources autonomously – and it failed. Of course the Ethereum Foundation needed to be involved, a bug of such size isn’t measured by the amount of money that was stolen, but on how could it affect the public perception of the whole ecosystem.

If you are inventing technology to build giant ships and the Titanic happens, won’t you be involved? If you are in the business of building new jet engines, shouldn’t you help investigate every new crash that could undermine the public’s trust in the whole airplane industry?

Of course, you can take the individualist position where, if you are not directly responsible then you should not get involved in other people’s business. You didn’t build that plane, you didn’t decide to cross the atlantic during iceberg season —why should you care? But it’s not the position I believe in.

It’s not that I don’t care about Blockchain immutability. In fact the Fork taught us two very valuable lessons:

• If there is even a small minority support, Blockchains can resist change and thrive, even if 99% of the miners, users and even the developers want to abandon it

• If there’s a large enough social agreement, a new social consensus can emerge and have more value than the original chain.

Unlike Bitcoin, ethereum was not created by a mythical creature that bestowed us with the magical Blockchain and disappeared into history. I believe not in One Immutable Blockchain, but in blockchains, a technology that can help us fight government corruption, manage public goods via software, reduce waste and increase transparency on markets. Ethereum was created by a group of flesh and bone developers that at some point in history could all fit in one small office in Berlin. You might feel that’s our weakness, that we are too centralised, too cabalistic, but I believe that’s our main strength, that we care and help each other, that we are willing to take unorthodox measures, do things that no one has dared to do, even if it sometimes goes against an unwritten religious tenet on what a blockchain should be, because we have a different vision on what it could be.

Who is this for?

This text is intended at those who have a basic understanding of web technology and how to build a simple javascript and html app, and want to convert these skills into building apps for the Ethereum ecosystem.

How can apps run without servers?

Currently servers in web apps do much more than what they were originally intended to. Besides serving static web pages, they also keep private information, handle user authentication and deal with all the complicated ways in which data is analyzed and saved. All the user computer does - a device which would be considered a super computer when the web was invented - is to load and display that information to the user.

Current server models

Instead, a more decentralized architecture would allow a much more modular approach, in which different machines and different protocols would handle specific tasks, some on the user's side and some in specialized machines deployed on a peer to peer network. Therefore all the Data logic (what gets saved, who saves it, how to solve conflicts etc) is handled by smart contracts on the blockchain, static files are served via Swarm and realtime communication over Whisper. The user device keeps the user authentication and runs the application interface.

Doing this would remove the danger of data breach and attacks as there are less single nodes keeping tons of unencrypted data, while also removing the load and cost of serving apps by distributing it across the network. Since all those protocols are decentralized, anyone can connect to the network and start providing a specialized service: if the user is browsing from a powerful laptop, for instance, they can also serve static files to network neighbors.

Decentralised Server models

A decentralized architecture also encourages innovation: since the interface is detached from the data, anyone can come up with a new interface to the same app, creating a more vibrant and competing ecosystem. Arguably, one of the most interesting and innovative periods in Twitter history was when it served mostly as a central data hub and anyone could build their Twitter Application.

See it working

If you want to experiment with the app before learning it, we recommend you download Mist and read our introductory tutorial to how to install the app and run it. If you just want to see the whole app instead, you can download it directly from the Stake Voice Github repository.

Stake Voice running on the Mist Browser

Let's get to it

We are going to build a very simple application called "Stake Voice". The idea is to allow ether stakers to vote on anything they want, and the app will tally the total ether balance of all those who agree or disagree with the statement.

The app underlying contract is written in Solidity, a javascript-like language and is very simple:

contract EtherVote {
    event LogVote(bytes32 indexed proposalHash, bool pro, address addr);
    function vote(bytes32 proposalHash, bool pro) {
        if (msg.value > 0) throw;
        LogVote(proposalHash, pro, msg.sender);
    }
    function () { throw; }
}

The first line sets up the contract name and the second creates an event called "LogVote", which will output in the log the following:

• a hash of the proposal being voted on

• if the voter agrees or disagrees with it

• the address of the voter

The function "vote" will then fire the log, which the application later will count. It also has a check that no ether can be sent accidentally. The “anonymous” function is executed when any ether is deposited on the smart contract and will then automatically reject it.

If you want to learn more about coding in Solidity we recommend you start on the ethereum solidity tutorials, read the official documentation page and try it on your browser using the online compiler.

That's essentially it: you choose a hash, choose a side and execute Vote(). So how does this translates into a polling app?

Serverless Architecture

Following the principle of KISS, we are doing the minimum product possible that is still usable, meaning we won't be using databases for storing proposals or using any feature that requires anything other than vanilla javascript and pure html.

So we will use the URL of the app itself to keep the proposal text, and we will use that to display it to the user and generate a hash that can then be used to check the votes. The users can use social media to share which proposals they want to debate or simply use direct links.

// On the initial startup function:
proposal = decodeURI(getParameterByName('proposal'));

// get parameter function
function getParameterByName(name, url) {
    if (!url) url = window.location.href;
    name = name.replace(/[\[\]]/g, "\\$&");
    var regex = new RegExp("[?&]" + name + "(=([^&#]*)|&|#|$)"),
        results = regex.exec(url);
    if (!results) return null;
    if (!results[2]) return '';
    return decodeURIComponent(results[2].replace(/\+/g, " "));
}

Start with basics

So grab your favorite html framework and get a basic website on your local machine and open it on Mist. All pages in Mist have access to a javascript object called web3 which will where you will be working the most. First thing we need to do is check if web3 is present or not:

Function init() {
...
if(typeof web3 == 'undefined') {
    // Alert the user they are not in a web3 compatible browser
    return;    
 }
 

Some application developers might want to load their own web3 object, to guarantee forward compatibility. To do that, just add just before </body> tag:

<script src="https://raw.githubusercontent.com/ethereum/web3.js/0.16.0/dist/web3.min.js"></script>

And then add this on your initial function to load your own custom web3 provider:

// Checks Web3 support
if(typeof web3 !== 'undefined' && typeof Web3 !== 'undefined') {
    // If there's a web3 library loaded, then make your own web3
    web3 = new Web3(web3.currentProvider);
} else if (typeof Web3 !== 'undefined') {
    // If there isn't then set a provider
    web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
} else if(typeof web3 == 'undefined') {
    // Alert the user he is not in a web3 compatible browser
    return;  
}

Load information from the blockchain

You checked you are connected to a blockchain, but which one? Is it the main ethereum network? Maybe a testnet or a private network? Maybe it's a fork in the future and your chain is a brand new one. The best way to check this is to see if the contract address you want to load has any code on it.

Furthermore, to execute a contract you need to know two basic things: it's address and the ABI, which will be a json encoded file containing interface information.

var contractAddress = '0x1e9d5e4ed8ef31cfece10b4c92c9057f991f36bc';
var contractABI = [{"constant":false,"inputs":[{"name":"proposalHash","type":"bytes32"},{"name":"pro","type":"bool"}],"name":"vote","outputs":[],"type":"function"},{"anonymous":false,"inputs":[{"indexed":true,"name":"proposalHash","type":"bytes32"},{"indexed":false,"name":"pro","type":"bool"},{"indexed":false,"name":"addr","type":"address"}],"name":"LogVote","type":"event"}];

Now that you have those, you can check if the contract exist on the startup function:

// Load the contract
web3.eth.getCode(contractAddress, function(e, r) {
    if (!e && r.length > 3)
        loadContract();
 })
 

You can even run this command recursively, to try connecting to it again using another address (in case you are actually on the testnet). Once you have found your contract you can load it up here:

Function   loadContract() {
// load the contract to javascript
      ethervoteContract = web3.eth.contract(contractABI);
      ethervote = ethervoteContract.at(contractAddress);
}

You are using the web3 object to create a new a javascript object that will be able to execute all the ethereum commands directly from the browser. If you want to load only a single instance of the contract, then you can even do it in one line:

    
ethervote = web3.eth.contract(contractABI).at(contractAddress);

Identify the user

Knowing the user's account reveals a lot of information about the user: how much ether and any other tokens it has on its balance, and their transaction history. So having all apps know this by default would create a super cookie and would be an unacceptable invasion of privacy. On the other hand, requiring the user to create an user account with login information for each site is not only a pain for the user, but also puts your private information in control of third parties, which creates giant honey pots that can be breached by hackers.

As a result of this dilemma most users have most of their personal information and authentication information handled by a half dozen billion dollar corporation. Privacy should not be a compromise we accept in exchange of practicality: users should be able to easily authenticate into any app while being in control of their own personal information.

Using Mist, apps have no information about the user, until the user decides to reveal itself to the app. When you want to query what you know about the accounts, you should call the getAccounts function:

web3.eth.getAccounts(function(e,accounts){
    if (!e) {
        // do something with the accounts
   }
});

Currently, the returning object is an array that holds simple accounts that the user has local access to, but in the future it will also hold smart contract accounts the user uses to identify themselves. This will allow the user to have access to features currently available only to centralized authenticators, like two factor authentication or cloud backup, and to future improvements only available to smart contracts, like allowing a few trusted friends to give you access to an account for which you lost keys or having automatic inheritance of inactive accounts.

Each future Ethereum browser will handle how users identify themselves to the App. In Mist we have two ways: either the user can initiate it by clicking the "connect" button (currently it's just called a "no accounts" button) or the App can request the authentication by calling the "requestAccount" api.

Attention: the accounts on this list are just one which the user claims to hold the key to, but the user has provided no proof of doing, therefore you can show a different UI, but don't send the user any secret information intended only to that account. If you require the user to prove their identity you need them to sign a message, while Mist will also support that in the future, keep it in mind that it would force the user to add an extra step and type their password, so you should only use that when absolutely necessary.

Voting

Once you have the contract as an object, voting is a matter of calling it from javascript. This will pop up a Mist transaction pane, where the user will be able to check the transaction and then type their password. So first we will create two clickable objects that calls a vote function:

    
document.getElementById('vote-support').addEventListener('click', function(){ vote(true);}, false);
document.getElementById('vote-against').addEventListener('click', function(){ vote(false);}, false);

Notice that one calls the function with a true parameter and the other false. The function vote could be as simple as:

Function vote() {
    ethervote.vote(proposalHash, support, {from: web3.eth.accounts[0]});
}

"Ethervote" is the object we created before, and "vote" is one of its functions, which correspond to one of the contract functions:

function vote(bytes32 proposalHash, bool pro) {}

We pass the two parameters demanded by the function and then add a third object containing transaction informations, like who is it being sent from and optionally, how much gas to include or how much to pay for the gas.

Consequently this would generate a panel asking the user to confirm the transaction - but most likely it will return an error because currently the web3.eth.accounts object is an empty array by default, so you have to check for that and if empty, request the accounts to the user:

function vote(support) {

     web3.eth.getAccounts(function(e,accounts){
        // Check if there are accounts available
        if (!e && accounts && accounts.length > 0) {
            // Create a dialog requesting the transaction
            ethervote.vote(proposalHash, support, {from: accounts[0]})

          } else {
            mist.requestAccount(function(e, account) {
                if(!e) {
                    // Create a dialog requesting the transaction
                    ethervote.vote(proposalHash, support, {from: account.toLowerCase()})
                }
            });
        }
    });
}

You should only request an account once the user initiated an action: pinging a transaction out of nowhere will deservedly irritate the user and probably make him close your app. If we observe abuses from apps using this feature, we might add more strict requirements to when an alert will show up.

Watch the contract

Finally, to count up all the votes we need to watch the contract events and see what votes were cast. To do that, we have to run this function once to start watching the events, after we instantiated "ethervote":

ethervote = web3.eth.contract(contractABI).at(contractAddress);
var logVotes = ethervote.LogVote({proposalHash: proposalHash}, {fromBlock: 1800000});
// Wait for the events to be loaded
logVotes.watch(function(error, result){
    if (!error) {            
        // Do something whenever the event happens
      receivedEvent(result);
    }
})

The above code will start reading all blocks from number 1.8M (when the contract was uploaded) onwards and then execute the receivedEvent() function once for each event. Whenever a new block arrives with an event this function will be triggered again so you won't need to call continuously. So what would this function do?

Var voteMap = {};
Function receivedEvent(event) {
    // Get the current balance of a voter             
    var bal = Number(web3.fromWei(web3.eth.getBalance(event.args.addr), "finney"));
    voteMap[res.args.addr] = {balance: bal, support: event.args.pro};
}

From the original solidity contract, you can see that the LogVote event comes with three argumenst, proposalHash, Pro and Addr:

event LogVote(bytes32 indexed proposalHash, bool pro, address addr);

So what this function does is that it will use the function web3.eth.getBalance to check the current ether balance of the address that voted. All balances always return numbers in wei, which is a 1/1000000000000000000 of an ether and is not very useful for this particular application, so we also use another included web3 function which converts that to any ether unit we want. In this case we will be using the finney, which is a thousandth of an ether.

Then the function will save the balance, along with the position of the voter to a map based on the address. One advantage of using a map instead of an array is that this will automatically overwrite any previous information about that same address, so if someone votes twice, only their last opinion will be kept.

Another thing we could do is identify the user and show them if they voted or not.

// Check if the current owner has already voted and show that on the interface
web3.eth.getAccounts(function(e,accounts){
    if (!e && accounts && accounts[0] == res.args.addr) {
        if (res.args.pro) {
            // User has voted yes!
        } else {
            // User has voted against!
        }
    }
 });

Tally up the votes

Finally, we should add a separate function to calculate the sums of the votes:

calculateVotes();

Why do we want to tally up the votes on a separate function? Because since the vote weight is based on the current balance of each account, we should recalculate the balances at every new block, event if we received no new event. To do this you can add this function that will execute automatically everytime a new block arrives:

web3.eth.filter('latest').watch(function(e, result){
    if(!e) {
        calculateVotes();
    }
}); 

Finally, up to calculating the final tally. We have previously used eth.getBalance in synchronous mode, where the app would wait for the result of the previous action to proceed. Here, since we can be calling a lot of actions every block, we will use it in asynchronous mode: you call the node and execute the action whenever it replies without freezing the interface.

var totalPro, totalAgainst, totalVotes;
function calculateVotes() {
    totalPro = 0;
    totalAgainst = 0;
    totalVotes = 0;
    Object.keys(voteMap).map(function(a) {
        // call the function asynchronously
        web3.eth.getBalance(a, function(e,r) {
            voteMap[a].balance = Number(web3.fromWei(r, 'finney'));
            if (voteMap[a].support)
                totalPro += parseFloat(voteMap[a].balance);
            else
                totalAgainst += parseFloat(voteMap[a].balance);
            // do something cool with the results!            
        });            
    });
}

As you can follow on the code, what the app is doing is looping in each of the voting addresses and getting their balance, and as soon as it returns, it will either add it to the pro or against camp and sum the totals.

Extra Goodies

A few extra caveats: when there are no events, nothing will be returned and votes won't be calculated so you should add a timeout function on all functions that rely on events from the blockchain.

setTimeout(function(){
        // If the app doesn't respond after a timeout it probably has no votes
    }, 3000);

Now you can feel free to use all your current webdeveloper foo to work whatever magic you want. Use the numbers to build a nice visualization in 3D or connect to your favorite social media to share the best questions.

Mist also tries to simplify your code by providing some basic navigation and UI methods. If you want your app to be header less and occupy the full height of the mist app, just add this to your <head> tag:

 <meta name="ethereum-dapp-url-bar-style" content="transparent">

And if you want to use Mist itself to navigate on your app, you can use the Mist.menu object:

for (item of propHistory) {
    if (item.length > 0 && item != 'null') {
        mist.menu.add( item ,{
        name: item,
        position: n++,
        selected: item == proposal
        }, function(){
            window.location.search = '?proposal=' + encodeURI(this.name);
        });
    }
 }

One great thing about ethereum is that you can expand on this simple contract functionality without needing permission: you can add all extra functionality on separate contracts, keeping every single one of them simple and easier to debug. It also means other people can use the contracts you created to their own apps and give new functionality. Meanwhile, all the apps use the same data and backend.

You can play with this app live hosted on github pages, but this isn't the canonical source of truth, just one of the many possible interfaces to it. The same app will also work as a local html file on your computer or on an IPFS network and in the future it will be downloaded directly via Mist using Swarm.

Some ideas on how you can try:

• Create a listing of currently available statements. Anyone can check them by seeing the sha3 of the proposal text, so you don't need permission.

• Create threaded comments where users can reply to statements and then upvote or downvote them, sort of like a decentralized stake based Reddit

• Instead of (or in addition to) using ether balance, you can use some other ethereum token, like The DAO or Digix Gold to weight your questions differently. Since all that the original contract stores is the sender, you can check all balances. Or maybe you can create your own currency that is based on reputation, karma or some other way.

• You vote by committing not to move your ether (or DAO tokens) for a given period of time IF a given fork is activated (or none is). The more ether you lock and the longer you are willing to hold it (last one is squared) the more weight your vote has.

• The fork which has the largest amount of people willing to lock is also, by definition, the one in which the least amount of people want to jump ship because they don't want to be involved in the project anymore and should be the more valuable chain long term, meaning miners and exchanges have the incentive to adopt it.

Since I last proposed this, I made some changes to it:

• Each vote is a separate contract, which can only be operated by it's owner, this reduces the risk of a bug that affects everyone.

• You can also vote with DAO tokens (since this is the reason we are debating it) - or actually any other coin. How these are calculated is a different manner but for simplicity sake we can make 100 DAO : 1 ether or whatever was the price at the end of the crowdsale.

• The maximum period is set at 3 months, which is a long time in this space. There is no minimum time to hold, but since the vote weight as (lock date - fork date)² anyone holding for less than a day will have their vote weight drastically reduced. The 3 month limit also limits the chances of there being another vote coming up before that.

• You can support any number of fork proposals, with different lock dates.

• The lock is only activated if there is a large support from miners. They can start the lock at any point and they also have the power to unlock everyone's coin if something comes up.

Here's the source code

Why?

I think pure coin votes are fundamentally unjust, as very few people have much larger power. I don't feel we should be building a system in which the wealthiest minority or an angry majority have unlimited power over everyone else's property and wealth - history has shown that neither of those create a nice society.

If we are going to open a precedent to decide on either to fork or not and which fork to choose, then we should at least try to make some system that can be built right now and makes some sort of sense.

PS. I am also working on a mist Ðapp that will be pure coin vote but I don't feel it's really good for such an important decision.

Since Friday I've been in contact with a group of very smart people with the intent on replicating the attack to avoid any more of the ether being bled. Let's call this group, collectively "Robin Hood". Everyone in this group acted as an individual and did not represent or received the endorsements of their employers.

Robin had been able to replicate the attack on the testnet but couldn't be sure it would work until it was tested. First it would require the group to successfully stalk and infiltrate multiple split proposals that were open.

After some initial setbacks the group was able to infiltrate all open split proposals and trying to identify the best one to execute.

The best candidate proposal ended up being #78 because it didn't have many stalkers and we had identified the curator. We control 3 of the 5 accounts that split with us, if you have any information on who are the other accounts, please contact us so we are able protect the funds.

The group was diverse in their opinions on the fork(s). Some are very strongly anti-any-fork, some are very strong pro-fork and everything in between. Despite our differences, we identified an imminent attack we worked together to prevent it. For that reason everyone was also reticent on doing the White Hat Attack as it could be bad for the recovery efforts on the past hacks. Also, even those in the group that supported the soft fork could agree that we had no idea how long it would take to implement and deploy one.

Today about 19h central european time Robin detected that there was a new attack going on. It was draining slowly, a few ether per round, but it had already amassed a few thousand dollars. It seemed to be someone testing the waters and seeing if it could drain more.

Having our hands forced, the group decided to go forwards with the attack. I donated 100k dao tokens to the process with the full knowledge that it could be burned in the process. The more tokens the Robin contract had, the faster it could syphon the ether to protect it. The attacker picked up the pace and other attackers joined in. Some of the most efficient hackers were able to do up to 30 recursions with up to 200 ether moved in each, so it became clear that if we didn't do anything the DAO would be drained before anything could have been done.

We contacted some "whales" who were happy to donate to the effort and we were able to secure about 6M DAO tokens. We made it clear to everyone that we were not sure they would be able to recover these tokens, but these generous friends were happy to contribute to the effort. Thanks to this we were able to outpace the attacker, doing 4,000 and then at up to 40,000 ether per round, totaling up30 rounds of recursions.

All these attacks can be studied on the blockchain. This is the child DAO of the Robin Hood attack.

These three child daos were the ones in which a concurrent attack drained ether: 84ef, f4c6 and aeeb. We know nothing about them and if any of these are parallel white hat attacks then this is the right time to come forward. If you happen to be the curator of any of these child daos, or happened to have split with them into one of them, please come forward as well do come forward as well as you can help with this effort. There might be others.

What now?

7.2M ethers from the DAO are now held in a child DAO and we hold the private keys of the curator. It's important to identify the other 2 - but the risk has been reduced from 20 thousand attackers down to only 2. As soon as that DAO matures, we will try to move all the funds in a refund contract, that will be much simpler than the DAO was. Of course we still need to be very careful with that code and to analyze it for any possible exploit.

If you own the addresses 0xb97ba16dfafa8fc5824c029f0653cc03a1796e99 or 0xe1e278e5e6bbe00b2a41d49b60853bf6791ab614 please come forward.

There is a lot of unaccounted ether, on the main attacker dao and other copycat attacks. If you are the curator in any of them, you might be very useful. If you are the hacker, then all I can say is we are coming for you. There are many plans in place to attack the child daos and either block the funds or recover them.

What about forks?

I've made my opinion clear many times about my opposition to a hard fork that breaks code or balance immutability, so I don't think this is the place to discuss it.

The child daos are also vulnerable to the same kinds of attacks so it's important to identify everyone else on the same child dao as the main whitehat. There are very valid points for a limited, voluntary, temporary software upgrade in which miners will be able to prevent other attacks like this from happening, and they may be used to prevent further attacks on these child DAOs. We now hope we bought enough time to stay calm and rational about these.

What about what's left in the DAO?

There are still plans to retrieve the remainder of the DAO and I can't discuss it further. But most of the ether is now more secure and there are some interesting advantages on having some money left which will allow the DAO itself to buy tokens into the bad splits and attack them to recover or block the ether.

Whoever is doing this is doing it on their own and is not related to our community at all

Since we had problems with spam before, very young accounts can't even post on this subreddit. I have no idea who might be doing this but they have admitted doing it and are using a lot of hours old accounts.

• This forum is for discussions about the technology behind ethereum, it's impact on society and implementations. We ask Price speculation and all kinds of rollercoaster drama to be moved to /r/ethtrader so spamming because of price is not in the spirit of this community

• The Ethereum foundation and most of the developers here own bitcoin and the ethereum technology owns bitcoin its own existence. The current Bitcoin debacle brings us no joy.

• If you are looking for uncensored bitcoin information I personally recommend /r/btc and /r/bitcoin_uncensored and /r/cryptocurrency

• Unfortunately while we can and we do ban sock puppets, we can't do anything about direct messages.

• if you are genuinely interested in smart contracts and Ethereum as a technology, please take a look at our quick start guide

To end this discussion:

“We have to let go of the notion that in order for Apple to win, Microsoft has to lose. We have to embrace the notion that in order for Apple to win, Apple has to do as a really good job. If we screw up and not do a good job, it’s not someone else’s fault, it’s our fault”

UPDATE

I got a reply from Reddit admins about the issue:

re: Spam in private messages

Hi there. We are aware of the issue and are dealing with the spammy accounts. The person or people behind it know what they are doing though so we are playing Whack-A-Mole with them at the moment.
It seems to have calmed down of late though. Have you gotten any recent reports?

UPDATE - Jan 27

After a quiet period, I'm getting more reports of the spam account and have even received one myself (again). Also we are working to delete a lot of spammy comments and posts claiming they sell ether.

Finally, we've had reports of someone impersonating Ethereum developers on IRC and attempting to scam people by selling ether. Please pay attention and do not fall for that!

What is Ethereum?

• BBC explains Ethereum

• Ethereum the world Computer

Where do I start?

• Download the wallet and build your own cryptocurrency

• Using the Wallet part 2: build a Democratic Autonomous Organisation

• Using the Wallet part 3: build your own transparent Central Bank

• Learn Solidity, the main language for smart contracts

• Build apps using Meteor and the ethereum tools

Devcon Videos

• Devcon1 (2015) playlist

• Devcon0 (2014) playlist

Technologies and Apps

• Do you have to use Meteor for building Dapps? Not at all! You can use any frontend GUI you prefer (even plain javascript), just connect to your node. We just use it internally for our Dapps and our lead Dapp Developer Fabian has built a lot of useful tools for that platform.

• How do I include web3.js on my apps? Here's a primer

• How can I store big files on the blockchain? Swarm and IPFS

• Is ethereum based on bitcoin? No, we use bitcoins underlaying technology, the blockchain, but Ethereum is a separate Blockchain. Ethereum has one of the first working implementations of bitcoin side chains so you can easily and quickly exchange ether and BTC.

• What tools should I use to develop and build apps? Ether.camp and Mix

• What other cool apps are being built? see this awesome constantly updated list

• What's the future of Ethereum? We are planning a switch to Proof of Stake in the near future. We are also investigating scalability solutions and how to store secrets on the blockchain

• No, I mean, how can I use ethereum to get information about the future? Augur and Gnosis are building prediction markets that try to gather the best information about uncertain future events

• No, but I want to discuss future price movements by scribbling graphs on trading charts! Then you should go here (not moderated by us).

We are going to modify the token contract to allow it to be minted by your DAO. So save the address of your current DAO in a note pad (pay attention to the icon) and grab this source code and you know the drill: contracts > deploy new contract > solidity source code > pick contract

You can fill the parameters any way you want (yes, emojis are permitted on the string fields) but you'll notice one new field that didn't exist before: Central Minter. Here add the address of your newly created democracy contract.

Click Deploy and let's wait for the transaction to be picked up. After it has at least two confirmations, go to your democracy contract and you'll notice that now it owns a million of your new coins. Now if you go to the Contracts tab you'll see that there is a new DAO dollar (admin page) contract on your collection.

Select the "mintToken" function to your right and then put any address you own as the "target", and then the amount of new mints you want to create from thin air in their account. Press "execute" but don't press send! You'll notice that there is a warning saying that the transaction can't be executed. This happens because only the Minter (which is currently set to the DAO address) can call that function and you are calling it with your main account. But the calling code is the same, which is why you can simply copy it.

Instead, copy the contract execution code from the "data" field and put it aside on a notepad. Also get the address of your new "Mint" contract and save it somewhere.

Now go back to the democracy contract and create a new proposal with these parameters:

• As the beneficiary, put the address of your new token

• Leave etherAmount blank

• On the jobDescription just write a small description that you are minting new coins

• On the transactionBytecode, paste the bytecode you saved from the data field on the previous step

In a few seconds you should be able to see that the details on the proposal. Unlike the other fields, transactionBytecode can be extremely lengthy and therefore expensive to store on the blockchain. So instead of archiving it, the person executing the call later will provide the bytecode.

But that of course creates a security hole: how can a proposal be voted without the actual code being there? And what prevents a user from executing a different code after the proposal has been voted on? That's why we keep the hash of the bytecode. Scroll a bit on the "read from contract" function list and you'll see a proposal checker function, where anyone can put all the function parameters and check if they match the one being voted on. This also guarantees that proposals don't get executed unless the hash of the bytecode matches exactly the one on the provided code.

It's an older code, but it checks out

Now everyone can vote on the proposal and after the voting period has passed, anyone with the correct bytecode can ask the votes to be tallied up and the contract to be executed. If the proposal has enough support then the newly minted coins should appear on Alice's account, as if it was a transfer from address Zero.

Why a transfer from address zero? Because doing the opposite, sending a coin to 0x00 is a way to effectively destroy it, but more importantly, because it says so on the contract code. You can change that as you prefer.

And now you have a central minter contract that exists solely on the blockchain, completelly fraud-proof as all their activities are logged transparently. The mint can also take coins from circulation by simply sending the coins it has to address Zero, or by freezing the funds on any account, but it's mathematically impossible for the Mint to do any of those actions or generate more coins without the support of enough shareholders of the mint.

Possible uses of this DAO:

• The creation of a universal stable crypto currency. By controlling the total amount of coins in circulation the Mint shareholders can attempt to create an asset whose value doesn't fluctuate too wildly.

• Issuance of certificates of backed assets: the coins can represent an external currency or items that the Mint owns and can prove to it's shareholders and token holders. When the Mint acquires or sells more of these assets it can burn or generate more assets to guarantee that their digital inventory will always match their real counterpart

• Digitally backed assets. The Mint can hold ether or other ethereum based digital currencies and use that to back the value of the currencies circulating

Improvements Suggestions

There are multiple ways that this structure can be yet improved, but we will leave it as an exercise and challenge to the reader:

Right now votes are made by shareholders based on freely tradable tokens. Can instead membership be based on invitation, each member getting a single vote (or maybe use quadratic voting or liquid democracy)?

What about other voting mechanisms? Maybe the vote instead of being a boolean could be a more flexible arrangement: you could vote to postpone the decision, or you can make a vote that is neutral but still count to the quorum

Currently all proposals have the same debating period. Can you make that proportional to the value transfer being proposed? How would you calculate that to tokens?

Can you create a better token that can be automatically created by sending ether into it, which can then be retrieved by burning the token, at a fluctuating market price?

What else can the DAO own or do, besides tokens?

Creating a token is fun, but what is the value of a token that doesn't do anything new? We are now going to create a new contract that uses the tokens we just created. The contract will be a Democratic organization that lives on the blockchain and that anyone holding a share token will be able to vote on proposals.

So let's go back to "Contracts" and then "Deploy Contract" and paste the DAO source code on the "Solidity Source" field. Choose the contract "Democracy" on the Picker and then select these parameters:

• On the amount field you can add any ether amount you want your DAO to start with. Since you can send ether to it at any time in the future, if this is the first time you've been doing this then keep the amount at 0 and send the money later.

• On the sharesAddress field, paste the address of the token contract you just created. Pay attention to the icon and color of the little circle that appears by the side of the address. If it doesn’t match exactly the one for the contract you created previously, then there's an error.

• On minimumSharesForVoting pick what is the minimum quorum of shareholders that need to vote on an issue before it passes. Here you must put the integer number of the minimum token possible, so if you created a token with 2 decimal places, putting 500 here will mean that in order for a proposal to be executed then the number of votes must be more than 5% of the total shares of the company.

• minutesForDebating: this is the minimum time a proposal must be discussed and voted on before the results can be tallied up. Put a small number like 10 minutes if you want just to create something for testing, but put something like 20,000 if you want to store large amounts of ether, so all proposals must stay there for at least two weeks.

Your contract should be looking something like this:

After a few seconds you'll be redirected to a the dashboard where you'll see your new contract being created:

You can also see the link to the new contract on the "Contracts" tab. If it's not there (for example: if you are adding a contract that you didn't create) then you'll have to add it manually. To add that you'll need the contract's address and it's JSON interface, a string of text that explains to the wallet how to interact with the code. You can pick any name you want and press OK.

Click your new contract box and you'll see a contract page. If you haven't already deposited some ether on that contract, click on deposit and put some small amount of ether so you can test how this particular democracy works. If the contract already has some funds, click the "show contract info" button.

On the "read from contract" you can see all the functions you can execute for free on the contract, as they are just reading information from the blockchain. Here you can see, for instance, that the "sharesTokenAddress" is indeed the correct address or that there are currently 0 proposals on the contract. Let's change that.

On the "Write to contract" you have a list of all the functions that will attempt to do some computation that saves data to the blockchain, and therefore will cost ether. Select "newProposal" and it will show all the options options for that function.

For "beneficiary" add the address of someone you want to send ether to, then put how many ethers you want on the "etherAmount" (must be an integer) and finally some text describing the reason you want to do this. Leave transactionByteCode blank for now. Click execute and type your password. After a few seconds the numProposals will increase to 1 and the first proposal, number 0, will appear on the left column. As you add more proposals, you can see any of them by simply putting the proposal number on the "proposals" field and you can read all about it.

Voting on a proposal is also very simple. Choose "vote" on the function picker. Type the proposal Number on the first box and check the "Yes" box if you agree with it (or leave it blank to vote against it). Click "execute" to send your vote.

When the minimum voting time has passed, you can select "executeProposal". If the proposal was simply sending ether, then you can also leave the "transactionBytecode" field blank. After pressing "execute" but before typing your password, pay attention to the screen that appears. If there is a warning on the "estimated fee consumption" field, then this means that for some reason the function called will not execute and will be abruptly terminated. It can mean many things, but in the context of this contract this warning will show up whenever you try to execute a contract before its deadline has passed, or if the user is trying to send a different bytecode data than the original proposal had. For security reasons if any of these things happens, the contract execution is abruptly terminated and the user that attempted the illegal transaction will lose the all the ether he sent to pay transaction fees.

If everything went well you should be able to see the results of the vote in a few seconds. The "openToVote" parameter on the first box will turn to false while the proposalPassed will reflect if the proposal has been accepted or not. You should also be able to see that the Ether balance of the contract will go down and the equivalent ether will be sent to the beneficiary of the ether you wanted to send.

Now take a moment to let that in: you just created an organization that only exists on the blockchain, that obeys votes based on completely digital tokens, but yet it can move real value around and create a very real impact on the world. Also notice that the organization is not under your control anymore: it will execute only the exact code you used to create it, forever. You can't bribe it, you can't earmark it and the same rules apply either you are moving 0.01 or 1,000,000 ethers.

Can it get any better than this? Actually, it can. On our next post we will explore how you can use "transactionBytecode" to allow the DAO to execute any kind of ethereum transaction, even owning or creating other contracts. We'll also modify the token code to allow the DAO to control the amount of a token that exists on circulation and how to send it forward.

But first a short introduction: I am Alex Van de Sande and I am the lead designer on the Ethereum foundation. At DevconOne I gave a talk entitled "The Blockchain Versus The Average User" where I went into more details on the challenges to bringing the Ethereum ecosystem to the aforementioned "Average User", one of which is the difficulty of defining what that term even means. When personal computers were introduced they were advertised as being "to the rest of us", but the "rest of us" public they targeted was actually a very narrow audience interested in word processing, spreadsheets and desktop publishing. Today, those would be considered among the top tier geeks, just below the kinds of people that still fight over the merits of Vim versus emacs. I truly believe that one day your Candy-crush-playing grandma/grandpa will use the blockchain, just like today he/she uses databases and https connections without realising it (maybe when they convert blue diamonds won on one game into cows in another game by some other publisher). But right now, what I'm working on is bringing it to that next tier of users, the ones that can download an office suite and figure out how to use a spreadsheet but don't feel comfortable around command lines.

So if you consider yourself in that group, then welcome we'll guide you to some basic activities you can do in a few minutes in ethereum: Build your own cryptocurrency, building your own democracy and creating a central bank in the blockchain. We skipped the "Hello World" tutorial this time, but you'll do fine.

Download the Ethereum Wallet

Download the latest version of the Wallet

But enough talking, let's get our hands dirty with Ethereum! I might be biased but I'd say the best place to start is the Ethereum Wallet, a multi platform app that will enable you to send ether and ethereum based currencies, create and execute contracts.

The first thing you have to do on it is create an ethereum account. All you need for it is a strong password and you'll get it. In order to do anything you'll need to put in some ether: but don't worry you don't need much. Most of the contracts here will cost less than a tenth of a US penny. If you are just testing it, we recommend you switch to the testnet: go in the menu develop > network > testnet (morden) and then on develop > start mining. After a few minutes you'll probably have enough ether to test anything, so you can turn it off and save your computer resources.

The wallet only allows basic mining on the testnet, but if you want to try your luck on the real net, then you need a more advanced tool. This used to be a cumbersome process but now there are better easier tools: and we have new tools that will make that process much easier.

The AlethOne miner is a straightforward tool with two buttons: press one to start mining in your GPU and press the other to deposit your rewards in a wallet. Download it from the Turbo Suite, a set of power tools created by the C++ team to develop ethereum applications.

If you want to create smart contracts on the live network and can't mine you'll need some ethers. You can have a friend sent to you or you can exchange it for bitcoins on a cryptoexchange. If you are a bitcoin fan we suggest you keep on eye on the btcrelay project, a fraud-proof sidechain that will launch soon and allow quick exchanges between ether and bitcoin without a third party.

Create a token

The first contract we are going to create is a token. Tokens in the ethereum ecosystem can represent any fungible tradable good: coins, loyalty points, gold certificates, IOUs, in game items, etc. Since all tokens implement some basic features in a standard way, this also means that your token will be instantly compatible with the ethereum wallet and any other client or contract that uses the same standards.

Go to the contracts page and then click "deploy new contract".

Now get the token code from here and paste it into the "Solidity source field". If the code compiles without any error, you should see a "pick a contract" drop down on the left. Get it and select the "MyToken" contract. On the right column you'll see all the parameters you need to personalize your own token. You can tweak them as you please, but for the purpose of this tutorial we recommend you to pick these parameters: 10,000 as the supply, any name you want, "%" for a symbol and 2 decimal places. Your app should be looking like this:

Scroll to the end of the page and you'll see an estimate of the computation cost of that contract and you can select a fee on how much ether you are willing to pay for it. Any excess ether you don't spend will be returned to you so you can leave the default settings if you wish. Press "deploy", type your account password and wait a few seconds for your transaction to be picked up.

You'll be redirected to the front page where you can see your transaction waiting for confirmations. Click the account named "Etherbase" (your main account) and after no more than a minute you should see that your account will show that you have 100% of the shares you just created. To send some to a few friends: select "send", and then choose which currency you want to send (ether or your newly created share), paste your friend's address on the "to" field and press "send".

If you send it to a friend, they will not see anything in their wallet yet. This is because the wallet only tracks tokens it knows about, and you have to add these manually. Now go to the "Contracts" tab and you should see a link for your newly created contract. Click on it to go to it's page. Since this is a very simple contract page there isn't much to do here, just click "copy address" and paste the contract address on a text editor, you'll need it shortly.

To add a token to watch, go to the contracts page and then click "Watch Token". A popup will appear and you only need to paste the contract address. The token name, symbol and decimal number should be automatically filled but if it's not you can put anything you want (it will only affect how it displays on your wallet). Once you do this, you'll automatically be shown any balance you have of that token and you'll be able to send it to anyone else.

And now you have your own crypto token! Tokens by themselves can be useful as value exchange on local communities, ways to keep track of worked hours or other loyalty programs. But can we make a currency have an intrinsic value by making it useful? Tomorrow we'll show how tokens can be used as voting system in order to make collective decisions on the use of funds by creating a Democratic Autonomous Organization.

An important aspect of making ethereum Ðapps easily accessible is a name registry that will connect a human readable name to a hash for usage in IPFS/SWARM or any DHT system.

The name registrar is not meant to be the one and only name registrar on ethereum but rather a default registrar to be used by Mist to resolve names. It will be an user configurable setting.

Motivation

The goal of this contract is:

• To find the optimal price for names: create a strategy where the nash equilibrium for each player is to simply put down the maximum amount they are willing to pay for a name, and not create incentives for names to be overpaid

• To allow optimal usage of names: allow good names to circulate among those who want have better usages for it, while keeping smaller brands reasonably protected

• To make name markets as transparent as possible. Currently domain squatting is a very sneaky business that utilizes information asymmetry to sell names. This proposal, while still allows names to be sold or transferred outside this market, will create a last resort market where name prices are transparent and optimal

• Registering names should have an optimal cost, cheap enough to be inclusive, but not too much to allow excessive name squatting. This intends to describe the design and parts of the proposed system.

• Privacy by obscurity: give unpopular and niche domain holders a reasonable privacy expectation while making the most popular names evaluations transparent. Creating a spider that crawls all name markets is exponentially expensive.

Specification

The system will consist of 4 main parts:

Hash Registrar

The registrar itself is the contract that stores the basic data. If more data is needed it can be stored in other contracts, using this one as the reference. It doesn't use the name directly to reference the registry but its data. Keeping the names as hashes instead of plaintext has two advantages: first it allows privacy by obscurity, meaning that if the name isn't known enough to be in a rainbow table then you can't really know who the information is about. Second, it allows a more general purpose and future proofing use of the contract, as it can be used to claim ownership on anything that can be translated into hash, like devices, files, texts and other uses we haven't thought about now.

function getAuction() constant returns (address auction)
function getElection() constant returns (address election)
function getCollector() constant returns (address collector)
function setCollector(address _newCollector) returns (bool success)

The registry is set at startup with the address of three other contracts, the Collector contract, Election Contract and Auction contract, that have special rights. Only the Election contract can change the collector. The others are unchangeable.

function getRegistry(bytes32 _hash) constant returns (address _owner, uint _renewalDate,  uint feesPaid, string _redirectAddress)

It uses a hash as an index and attributes these informations to it: an address that owns it; the expiration date of the registration; the amount of ether that the owner effectively paid to the registrar address as the process of renewal; a string which is the http, buzz or ipfs address of the app.

Other contracts might extend this functionality by simply creating a registry of extra information about a hash and then only allowing edits to it by checking this master contract for the owner address. For example, the wallet app might want to make a registry where a name is associated to an address (different from the owner), or if you want to have a secondary content hash for http links then a secondary contract could be deployed, only allowing edit access to the addresses on marked as owner on this contract.

function editRegistry(bytes32 _hash)

All the information on that hash can be edited by the owner of the address up to 48h before the renewal Date, and at that time the information is locked. After the expiration date, only the Auction Contract can change the owner of the hash.

function newRegistry(bytes32 _hash, string _redirectAddress, address _owner)

Only the Auction Contract can add new registries.

function ()

All funds given to the Registrar contract are redirected to the Collector Contract. These will not count towards the feesPaid.

function invalidateEntry(string _name)

The disadvantage of hashes as identifiers is that it literally allows anything, therefore making it impossible to create restrictions such as "names shorter than 6 letters can only be registered after 2017". This could be avoided by creating validity rules that need to be reported and if true will delete the entry, but this would require all those rules to be set at the first setup. Another way to do it is to grant the Collector Contract power to invalidate entries, but this would open the possibility of an evil collector contract censoring entries. Another solution is simply to allow any entries, but simply enforce those rules on the client: mist could be programmed to look at other contracts for special names

I'm open to more elegant solutions.

Auction Contract

The auction contract is set at startup of the Hash registrar, but since they are separated it is possible to clone a copy of the registrar contract and just change these variables.

The purpose of the auction contract is to receive bids for hashes and select a winner.

function startBid(bytes32 _newHash)

If _newHash is not registered to anyone this will create a new register, owned by 0x000 with a renewal date exactly 7 days after this function was executed. This allows a short time in which a Vickrey Auction can decide who is the first owner of the name.

The cost of start a bid can be defined by the collectorContract, but otherwise is kept at free.

function putSealedBid(bytes32 _sealedBid)

A sealed bid is just a message with the hash of the bid and some ether. The amount of ether sent on this step is also recorded, as long as the time in which the bid was put. The amount of ether can and should be higher than the amount bid, to protect the privacy of the bid. For the same reason, the bidder doesn't need to be the future owner.

The collectorContract, might define a deposit value that needs to be added on top of the put, but if it doesn't implement it then it's free.

function revealBid(bytes32 _sealedBid, bytes32 _biddedHash, address _owner, uint _bidPrice, uint _duration, string _salt)

_sealedBid is the hash saved on _sealedBid
_biddedHash is the hash that the bidder wants to own
_owner is the future owner of the hash, if the bid is successful. The bidder and the owner need not to be the same person
_bidPrice is the maximum price the bidder is willing to pay for it
_duration is the length of time (in days) the owner wants to renew it for. Must be longer than 180 and smaller than 3660. If this is the first time this hash is being bidder on then the _duration cannot be longer than 366, if it has been registered before then the _duration cannot be longer than twice the length of time that has passed since it was first registered, as to avoid very long registrations during the first years.

_salt is just a random string to prevent deanonimization of sealed bids by brute force

This action can be done by anyone. If the _sealedBid doesn't match the hash of all other parameters put together then the bid is not revealed, otherwise it's saved on the revealed bids. Collection contract.

Once a bid is revealed, the proposed setup is a closed bid Vickrey auction, where the highest bidder becomes the owner but only pays the second highest bid:

• If the new prospective owner is not the current owner then his bidPrice will be the parameter on _bidPrice. If the owner is bidding to renew the name then his bid will be calculated as _bidPrice * K/ _duration. In practice this means that the owner is appraising his own name at that price and is putting down a Fee that is a percentage of the total appraised value of his name, proportional to the renewal period. That percentage is the same for all names and is decided by the Collector Contract

• If the expiration date is on the past, then the bid is deleted and the funds sent to it are sent to the Collector Contract

• Else if the duration is outside the bounds of minimum and maximum durations OR if the ether amount sent during the sealed bid isn't enough to cover his price and fees OR if the sealed bid has been sent less than 48h before the renewal period then the bid is considered invalid, it is deleted and the ether amount sent back to the bidder.

• If the bidPrice it's the highest yet then it should be saved as such and the price to be paid should be set at the asking price of the previous highest bid (or 0 if there are none). The second highest bid should be deleted and its ether sent back to its bidder. If the bid new owner is not the current owner, K is 1, otherwise (if it's the owner renewing the ownership) then K is a factor set by the Collector Contract.

• Else if the bid is lower than the highest bid but bigger than the price to be paid of the highest bid, then the price to be paid is set at the this bid asking price. This bid is deleted and its ether sent back to its bidder.

Should a bid be considered invalid if it's revealed earlier than 48h of the renewal date?

Bids revealed too early might affect the game strategy and will influence the price to be paid. In the other hand a deleted bid might mean that someone will lose his property without the correct asking price. Since losing a domain name is harsher than someone overpaying for it, then I suggest that there should not be an obligatory reveal period, only a suggested 24h window.

The collector contract can set a function that will determine a fee to be paid by the bidders, but otherwise it will default to free.

function revealBid(bytes32 _sealedBid, bytes32 _biddedHash, address _owner, uint _bidPrice, uint _duration, string _salt)

A bid can only be removed by the original owner and only earlier than 48 hours before the renewal date.

function finalizeAuction(bytes32 _biddedHash)

This action can be only executed after the renewalDate has passed. Anyone can call it, so it could be scheduled with the alarm clock.

If owner has not changed, then an amount of ether equivalent to _bidPrice/ _duration * K will be sent to the Collectors Contract and the remaining amount will be sent back to the original bidder. The amount paid will be registered at feesPaid. The renewal date will be set at the last renewal data + _duration.

If the owner has changed then amount of priceToBePaid will be sent to the previous owner, and a fee calculated by priceToBePaid * K / _duration will be sent to the collectors contract and registered as feesPaid. Otherwise a user could keep a name indefinitely by simply selling it to itself. The renewal date will be set at the last renewal data + _duration.

function cleanOldBids()

Deletes any unsealed bids that are older than the maximum duration time that any name can accept and forwards the ether to the Collector.

Collector contract

The Collector Address is an address that receives all the funds collected in auctions and has a special right to change the K factor. The purpose of the name registry auction is not to make a profit but to allow the optimal distribution of names, to prevent name squatting while still allowing cheap and easy access to registering a name. The cost of the renewal is given by the market price of the total price, divided by K. If K is too low it might allow name squatting, but if it's too high it can make keeping names too expensive.

The collector contract can also define fees related to bidding, in order to fight spam. The collector contract can determine which rules are broken in order to consider a registry invalid (short names could only be registered after a few years, etc)

How exactly the Collector contract changes the K factor or spends its funds is not defined here, as the contract itself is a changeable parameter elected by the Election Contract.

My proposal is that the first Collector contract be just a "Boomerang contract", a contract that simply keeps all ether sent to it and then send them back after 1 year. This will allow the funds to be safely kept for a period while the community build tools and DAOs for the collector contract for the first election. Since they can always elect the 0x address, then if the community wants to do so they can still vote to burn all the ether collected during the first year.

Election Contract

The election contract has the special right to change the collector address. The exact workings of the election, as well as their frequency is not yet defined here and is open to discussions.

One important issue is that it's impossible to tell which are the entities behind each name, if they coordinate with each other or if they are owned by other entities, therefore the concept of anti-sybil (and to a point anti-coercion) mechanisms does not really apply here. Also, the job of the Collector Contract is basically to define the use of it's own funds and how to raise or lower the "tax rate" on new names, therefore it's only natural that the weights of the votes should be based barely on the amount of funds each name has sent to the contract during their last renewing period.

A user that bought four names four 1 ether each and a user that bought a single name for 4 ethers have contributed the same amount to the collector contract and therefore should have the same right to decide how the funds are spent. If the system favours the former (like quadratic voting does) will stimulate users to buy tons of small names they are not going to use, a system that favours the latter will stimulate users to double bid on their own names to pay higher taxes and therefore get more voting power. Both will would be contrary to the whole purpose of the name registrar.

The suggested voting mechanism is a mix of approved voting with Liquid democracy, as follows:

function setDelegate(string32 _ownedHash, address _delegate)

Instead of voting directly, a voter instead can decide to appoint a delegate. The contract verifies that the msg.sender is the owner of the _ownedHash and then moves his voter weight ('feesPaid') to the new _delegate

function unsetDelegate(string32 _ownedHash)

The voter removes his vote to his delegate and states that wants to vote himself.

function setVote(address[] approvedCandidates)

The voter selects an array of contracts he approves for the job of Collector Contract. These remain static and can be changed anytime. If you

function tallyVotes()

Instead of a fixed election cycle, votes can be counted at anytime if someone feels voter's preference have changed enough. The cost of counting the votes is paid by the function caller. First the function will calculate the voter's weight by the sum of his 'feesPaid' and the weight of all voters that delegate their vote into him. Votes can be delegated forward a finite number of time (3, 5 or 7, depending on gas costs).

Then all addresses the voter approved will be receive an equal number of votes as his weight. The Address with a higher number of approvals will be selected as the new Collector Contract, effectively immediately.

Acknowledgements

People who contributed to this proposal, in no particular order: @nagydani & @zelig (with their research for the swarm name registrar), @vbuterin (for insights in elections), @gavofyork (who designed the first name registrar ), @yann300 and @arkpar (who implemented the current name registrar), @pipermerriam & @nmushegian (for their great insights at DevCon1) and @ryepdx (that is implementing the maker registry) and @danielnovy (auctions Ðapp at consensys)

• A P2P drone delivery system is built in ethereum. Anyone can buy their own drones, config them and add them to the network, and the system will pay for them. These drones will be used to deliver packets from anyone in a city to anyone else, very fast. It disrupts all delivery companies.

• The service is extremely useful, it grows and anyone can add charging stations, smart cars, or services to the network. Soon, there are whole companies dedicated to building and providing them with all kinds of vehicles.

• As the service connects to other distributed services, it's also used as drug delivery mechanism. Libertarians cherish, and governments decide not to outlaw the system because it's seen as useful and instead investigate the deliveries. Slowly, most local drug lords are outcompeted.

• The system develops a variable fee, it can predict how much high risk some deliveries are, soon it can also charge more for high value items high risk, so in essence, much of the drug money previously siphoned to crime is transferred to the mesh network. It's seen as a positive step for many.

• The system is lucrative, but drones don't buy mansions or spend it in prostitutes, all money is going back to buying more robots and expanding the service.

• Vehicles are created for international packet shipping: submarine, torpedoes, long range airplanes. The system is able to reach a container ship in international waters, and grab a packet directly from board. No law is being broken by a human so this is a very hard system to fight against.

• Governments start requiring automated drones to provide identification. Unregistred drones can be shot at will. This doesn't prevent them thou, as slow drones are shot, it only raises the profitability of faster and stronger drones. An arm race starts.

• Legal and illegal factories in china are dedicated exclusively for providing robots for the system. But soon, the factories themselves become DAO's as it's cheaper than CEO's. Maybe humans are still working there, but in bad conditions (just like they are now)

• A prediction market is created to siphon a bit of the money gained in causes that are believed to be good for the system as a whole. If your firm starts lobbying and campaigning for the system, you'll see the system starts just "giving" you money. They lobby for less government intervention, international cooperation, and for worse working conditions.

• The same prediction market evolves into an assassination market: if some person is identified as someone who is a powerful enemy of the system, it siphons money to anyone who can neutralize them.

• Asian factories are 100% automated and can be built anywhere. Reports appear that they are building weaponized drones. No country has ordered them, but someone is paying for them. Why?

http://forum.ethereum.org/discussion/751/so-i-designed-a-concept-ui-for-the-alephzero-client
http://forum.ethereum.org/discussion/711/web-components-marketplace-for-ethereum-ui-markup

The question is either Smart contracts should, in the future, have UI information. I see mainly two ways this could evolve:

* Ether contracts start having more code related to UI and how to present the information to the final user. New GUI elements are created and can be reused. Ethereum evolves into a whole decentralized OS.

* Contracts have information on what commands they accept and what's the data format or options each command takes. Ether provides the apis, and data for the backend of any app, in any platform. Clients can use whatever native OS code they prefer, and use Ether as the cloud api, a decentralized always persistent network.

I truly believe the second one is by far a better approach. First, because it's simpler and isn't a boil the ocean kind of approach. You don't need to implement custom interface elements, reinvent the browser, recreate 30 years of GUI code from multiple platforms.

Also, it promotes a separation of code in the Data/Model/Controller layer and the View/Interface layers. This creates cleaner and easier to maintain code.

Finally, it allows UI to flourish and Ether to be future proof. A OS built for the desktop isn't necessarily good for tablets and smartphones, and a mobile OS might not be good for wearables, robots or microwaves. OS's and interface needs change and separating Ether as just the data api we allow it to flourish in any platform.

A good example is Twitter clients. When twitter started, it was an open platform that allowed anyone to build clients on top. This created an environment where UI design flourished as everyone tested different approaches, on multiple platforms. The best innovative UI of the time came from twitter third party clients.

So in my vision, the reference client should only have a very basic "contract navigator" that permits you to use and test any contracts, but allows you to launch it in an external client for a better experience. This contract could have a list of accepted commands and a basic UI to provide the correct data in each command (a api request builder) but not more. The way data is presented, and how the interface is displayed, should be left to developers. (see attached)

Does everyone thinks similarly or am I too off the mark?

Of course this is a very rough sketch and shows only the contracts tab. I imagined it as a collection of all your active contracts, but added a few features that are not on the current code but seem no-brainer, specifically features in which a contract tells the client the kind of data it accepts (and what UI) and the current status of the client.

I'm also adding the ability of querying a third party of your choosing to audit and describe each contract, so you can trust it before.

Most features of the current AlephZero are visible on that screen. The "owned accounts" would be similar to the contracts page and the remaining status and blockchain could be tucked in the "network" screen.

I'm using Retro gravatars to identify contracts because they're much more instantly recognizable than hashes, and I believe they are much better than the traditional "kaleidoscope" gravatars. I didn't pick or choose any, but you can still read an image in all of those random patterns.

So what does the community think? Is that kind of contribution welcome? How can I help in a more productive way?

Thanks

Here's a true story that migh help get things started:

There's a pacific island that or many centuries, the only currency they had were round disks of a given stone. But that stone isn't exist anywhere in the island and the disks had to be produced far away and brought back to the island by canoe, making the process very hard. Because the biggest the stone, the harder they were to carry, the bigger were more valuable and by the 16th century most "coins" would weigh over a 100kg, making them impossible to carry.

But still they were very valuable, used mostly for important trades like a dowry or a home and owning just one would make you a wealthy man on the island. But since they were so cumbersome to carry, they could be traded multiple times without ever being moved: trades/gifts were made in public gatherings and everyone knew whose stone belonged to whom.

One day an islander was bringing home a great and beautiful coin that he had labored over months in the other island when his canoe flip sides and the coin went to the bottom of the sea.

Luckily everyone in the canoe survived and had seen the stone and told everyone in the island about it. So since everyone knew the stone actually existed, it still held value and could be traded like the others. Like most stones it wasn't moved but everyone knew who was the current owner of the stone in the bottom of the sea...

Some reflections:

1. Why did the villagers "decide" to use a kind of stone that wasn't available in the island? Couldn't they use a more common thing like seashells?

2. If the stones didn't actually need to be moved to hold value, why bother moving them into the island in the first place?

3. Like the stone in the bottom of the ocean, you rarely actually see the money in your bank. When you send money to somewhere else, what the bank actually moves?

4. The stones still exist today and are sometimes given as symbolic gifts in weddings but their demise as an economic system ended when Europeans started trading island goods with large quantities of stones they were bringing themselves. What piece of technology ultimately ended up destroying that economic system and what exactly did it do?

Suppose bitcoin achieves the most optimist scenario where its an essential part of the modern world economy, used for trade worldwide and seen as something that's not going away ever. In this scenario, each bitcoin is worth a lot and mining equipment is very expensive, mostly owned by people who are in for the money — maybe they're banks, corporations or just individuals but what matters is that the pure idealists are the minority.

Now there's a schedule block reward halving coming up. Then someone finds some flaw with that: maybe its technical, maybe it's an economic argument, what matters is that, like the Y2K or bank bailouts, its very hard to actually know how big a problem it will be until it actually happens. There's a chance it's a non issue, but there's also a chance that it will be a problem and then the whole system will be crumbling down and we can't afford that risk now can we? Bitcoin will be too big to fail.

Many heated arguments are held but you know that saying: "it's hard to make someone understand something when their paycheck depends on him not understanding it".. In the end most miners have an economic incentive to believe the issue is real: after all this hipotethical issue is not completely made up, there's some nugget of true.. More than half then agree on postponing the block reward halving until the issue is addressed. They're not creating more money, just buying some time.

But then that temporary thing becomes permanent because no one wants to halve their paycheck voluntarily. And sudennly bitcoins are expected to go over the 21 million limit. People complain but since most of the complainers holds bitcoins they don't want for everything to crash..

Once the cat is out, no one can tell what happens next. Maybe the block reward goes up. Maybe the block rewards gets permanent. Who gets to decide it? The same people who profit from it.

TLDR: At some point miners will have the power to rule over their own rewards. What prevents them from abusing it?

Colored coin is an innovation on "smart properties" the concept of taking a few of your satoshis and giving it some value that is bigger than the nominal value of bitcoins on them. Because all coins can be tracked to their origin, anyone can keep check of ownership of those coins. For example a bank can issue a bunch of promises saying "I promise I will give the owner of this satoshi an ounce of gold" and then sell those colored coins at however price other people are willing to pay.

Or, for example, Bitpay could whenever someone asks to convert their bitcoin payments in dollars could instead of just adding it to it's internal database, give the owners colored coins that were worth bitpay credits, redeemable for a fixed amount of dollars.

This is where P2P exchanges get in. Imagine that whenever you open an account and deposit money in Mt Gox, instead of that credit being stuck inside MtGox servers they gave you back in colored coins worth "MtGox Dollars". As long as you can find someone that trusts in MtGox, you can exchange those MtGox dollars for any amount of bitcoins you could agree on, just using your own bitcoin client.

If someone is willing, he or she could also accept MtGox directly for a payment for a service, or exchange it for colored coins of other denominations, like BitInstant Euros, Silk Road Pounds Or Shady Pirate Gold.

Thus along as you trust the issuer, you could never hold bitcoins, but hold any other currency you wish. You might not trust the value of bitcoin longterm but if you can still use cryptocurrency innovations to hold a diverse portfolio of gold, dollars, euros and bitcoins.

Even if you don't trust completely the issuer, you can still use the system. Say you owned $100 worth of BitFloor credits in colored coins. Even if Bitfloor is shut down by it's corporate banks, if some other entity is willing to assume it's bill – say the completelly unrelated Bitfloor Cayman Islands Inc – they can accept that credit and exchange for something else. Or you can request that any "colored coin" is worth at least an x amount of satoshis – so if Shady Pirate Gold Corporation just disappears, you still have a minimum amount of bitcoins.

If this sounds like reinventing fiat money, this is exactly what it is: a 21th century reinvention of 18th century non-governamental private banknotes. It might not be your cup of tea but those are very welcome innovations and could really be useful for everyone.

How can you help?

• If you're a bitcoin client developer, build colored coin support in your client.

• If you host a bitcoin related service, try seeing how you can integrate colored coins on your project

• If you own an account on any exchange or fiat money conversion service, write them and ask them for colored coin support

• If you are a bitcoin holder, help with bitcoin bounties by chipping in for a colored coin related bounty

• If you are just a bitcoin enthusiast: look for clients and services that support colored coins, and inform others of these when you see any discussion on the matter.

• If you're neither of these (what are you doing in this subreddit??): check Ripple.com an alternative cryptocurrency that tries to solve the same problems of holding multiple currencies in a very different approach

When people ask you about bitcoin, avoid talking about the current price or how it exploded, because then you'll be talking about bubbles, pyramid schemes and the inherent value of things, and all that is irrelevant to bitcoin. Yes, I have a few and I love seeing my money grow when the price goes up and buying it cheaper when it goes down. But that's just a gamble: here's what made me stick to bitcoins.

Bitcoin is a money API. It's a technology that allows computers to move wealth around in a more efficient manner, allows contracts to be abided by programming not lawyers. Bitcoin has the potential to change society as much as the internet and Peer to peer has before it. Right now bitcoin is just trying to be a better paypal, but, just like the web started as a better way to store electronic documents, bitcoins can be a lot more than that.

Take a look around and think about how many institutions exists, how many people are employed, energy spent, how much space is devoted to the simple act of moving wealth around, to guarantee money will exchange hands and go to the right person: all of those can be made more efficient and sometimes completely redundant with bitcoins.

And if history taught us anything is that geeks with efficient systems tend to win over traditional unmoving inefficient ones.

I have a friend that once visited a company whose job was to guarantee electronic transfers between banks. It was a highly complicated, very expensive, ultra regulated operation. He explained to me that the reason that electronic transfers between banks in brazil costs $5 and are limited to a minimum of $3000 is merely computing power – if they lowered those numbers they couldn't cope with the excess information. Inefficiency.

Banks aren't the only institutions that exists solely to regulate transfer of money: so are insurance companies. An insurance is nothing more than a reverse lottery, where everyone pays every month and if something happens you get back a prize. A small group of developers could develop an insurance company that could be much more efficient than regular companies: the whole part of handling money, collecting it, figuring out who paid and who didn't, the covered conditions could be programmed in the system from the start. All that is needed is a way to check if the subscriber needs to be paid or not: but that's now an engineering problem, not an administrative one. You could check nasa for weather and tornado information, google maps, use flying drones, pay agents, check hospital records, crawl newspapers for crime and obituaries news. The more you think about them the more institutions could be perfectly replaces by one automated script that moves money around.

Bitcoin is codified money. If you believe that then enjoy the ride up. If you're into it just as a get rich quick scam, then throw it all on satoshi dice.

Mercado Bitcoin, the largest – and only – bitcoin exchange in Brazil, has been offline for almost a week now. For the first few days there was no communication, but the owner just sent an email to all accounts explaining he was hacked. I haven't seen it posted anywhere in English so I'l do my best to translate what I got.

As far as I understood, someone hacked his "redeem code" feature, being able to generate false credits in the system. Then during the night the hacker moved out all his credit into bitcoins, leaving MercadoBitcoin without enough BTC to pay back all the other depositors.

Mercado hasn't revealed how much was robbed or more details than that, but has said he will try to pay back what he can, in that order:

1. Withdraws in Reais that were requested before the attack

2. Deposits in Reais that hadn't been credited yet

3. Current balances in Reais

4. Current balances in Bitcoins

Meaning that depending on how much was left, bitcoin balances will only be given back if he is able to pay back all the money (in Reais) to other creditors, and even that money isn't fully guaranteed.

I posted about MercadoBitcoin last week when I wanted to share the word that Bitcoins in reais where 25% overvalued over other currencies. I assumed it was mostly because of the small amount of sellers but it seems there was also another factor: lack of trust in the exchange.

I doubt this attack is related to this reddit post: this week Exame one big financial magazine in Brazil also had a feature in Bitcoins which mentioned the Mercado. Either this was an opportunistic hack or just a case of worse timing, it seems that the adoption and reputation of Bitcoins in Brazil has received a bad punch.

For example: if you buy 10 bitcoins right now in dollars (or euros) you'll spend $733.80 dollars. Those same bitcoins can be sold for R$1750 which at the current exchange rate is worth $868 dollars. So you could make $150 dollars extra, which would more than cover any exchange tax, a couple of caipirinhas, a hotel room for the night and you've still got some bucks left.

Check it for yourself at: http://www.mercadobitcoin.com.br/

I expected this to be a temporary thing, but as I said, I've been watching it for a long time and the difference has been constant. I suppose that if enough people do this, the bitcoins offer in the market will catchup with the demand and the price will go to a saner level – which is exactly what I'm spreading the word around.

I’m a big believer in making things simply beautiful, that the correct line is a beatiful one.

Tarot isn’t more a divination game than making fridge magnet poetry, so when I decided to build a tarot app for iOS I tapped on that fountain. I created this app from scratch: from design, to code, to the interpretation algorithm and the subtle animated transitions from states.

Download from the AppStore

A Facebook app for fun profile games.

This is what I would call a “skunkworks” facebook game. The company was under a reestructuration so many of the design projects we were working wer canceled, new ideas were outright rejected because our IT was already too busy or because they had no short term revenues. This left our the design team with a lot of idle time. Instead of slacking off, I recruited them to make a facebook app, which would be a good opportunity for teaching them some HTML and CSS basics and a great opportunity for me to learn more about the facebook app development process. All coding was done inside the team, using our own servers.

At first when the project was launched and revealed to the company it got a lot of rolling eyes, because it could “take visitors away from the site and into facebook”. But not long after the company run into a problem that they had more ad contracts than space to deliver them, and the App fell like a glove. To this day, the app still works as a alternative revenue place, with special profile tests created for promoting books and product giveaways, and helping to bring more users to our company page.

Cartola is a Fantasy Soccer game created by Globo.com where soccer fans can put their (virtual) money where their mouth is. Users create soccer leagues where they buy and sell real world Soccer players and see how well their investment pay when the price goes up and down related to their actual performance.

I was responsible to build the Visual interface to the iPhone and iPad port of what was originally a web-only game.

Cartola in the AppStore

Understanding how things work is the essence of good design. I’m not personally a fan of Astrology but I do love astronomy and both are very closely related (and in some ways opposed).

By understanding how orbits actually work, I pushed the developing team to go beyond a simple horoscope app and bring real world content, using planetary data from Nasa’s website to build a small virtual Orrery in your phone. The app shows people not only information about their Astrological sign, but information about it’s related celestial constellation: where it is in the sky, how to look for it on the sky, what planets are in transit and what this means in the Astrological mythology.

Not only this makes for one of the most visually interesting Astrology software in the AppStore, but it also hopes to make people more interest in the sky above them, by connecting their spiritual symbols to their real world counterparts.

By undertanding how both Astrology and Astronomy correlates, we were able to create a rich and respectful Astrology App that differentiates itself from it’s competitors.

Estrela Guia in the AppStore

Frugar.com is currently a site for organizing lists of your favorite things – but it wasn’t always that. When I first came into the company it was intended to be a feature phone application for shoppers, which evolved into a barcode reading app for iPhone and into a social network for reviewing products.

I worked as both a Designer (in the earlier versions) and a web developer for Frugar, going through six pivots of the company, an intense learning experience of the inner workings of a startup company.

Frugar.com

The mobile site for the biggest newspaper in Latin America. One of our first big clients.

The biggest internet company focused Women was going through many renovations in 2011 and needed to reflect it on their home page. Our focus was to do a total revamp of the brand and site look, in short notice and but without needing a total rewrite of the complex and hard to maintain custom content management used. I was the leader of the team in charge of changing the main page.

In about four weeks we were able to using mostly CSS and the fewest possible infrastructure changes, create a total portal page, more modernized and showcasing the content the team produced.

Site for collecting and organizing Deals from deal sites. In 2009-2010 deals sites became a gigantic craze in Brazil, earlier and in a much different way from it’s american counterpart. While in the US, the game was dominated by a few early players in Brazil there was a new Daily deals site created every other day.

Localized to small cities, to specific groups or very niche market at some point in 2010 there was more than 200 different sites using the same business model: selling coupon codes that could later be claimed for discounted items or service.

Instead of building another deals site we focused on building a service for people who used them: a central repository for your coupon codes, available anywhere you went, compatible for any device. The idea was to make it as easy to register a code as forwarding an email, and the site would take care of the rest, pinpointing the establishment on a map and alerting you by email when the deal was about to expire.

The site was built in the model of a responsive webapp, the same codebase and a changing CSS to adapt to any device screen size, allowing you to even run it full screen from your iPhone home screen.

Cuponzal

A Webapp for accompanying online the results of the highly digital national Brazilian Election.

An intense development during weeks, including a total interface rehaul in the last minute, for a few hours of use.

era um plano simples. O que pode dar errado afinal?

a surpresa parte II: tentativa um

Lembram a primeira semana onde só fez chover e fazer sol no mesmo dia o dia todo? lembra, há tanto tempo atrás? pois é.

E o mais triste é que nunca escondi nada dela e dessa vez nao podia dividir nada...

a surpresa parte III - Porquê ainda não pedi ela em casamento?

meu cabelo cresceu o bastante pra voltar a ter rabo nesse meio tempo.

a surpresa parte IV : domingo de sol

a surpresa parte 5- sobremesa

na verdade não era um pudim, mas esse fica mais gráfico. Hoje estava sem vontade de colorir

‹1 / 2›

a surpresa parte 6 - como fazer pra tirá-la de casa?

ok, prometo, no próximo já começa a parte da surpresa em si.

a surpresa parte 7: na praia

eu decidi que nesse ritmo não termino a história esse ano e não quero passar a vida toda nesse dia. vou acelerar um pouco

a parte boa é que o meu tempo está sendo comido por trabalho...

a surpresa parte 8 - finalmente, o dito cujo

claro que continua.

subiu? caiu? será que morri?

a surpresa 9 - Quatro fatos sobre a experiência de voar de balão

descobri que gosto de desenhar paisagens...

‹1 / 2›

A surpresa parte 10: Enquanto isso, no aeroporto..

Esse é uma homenagem ao bruno, o tipo de amigo que guarda um cartaz de 9 metros quadrados fedendo a tinta durante um mês. Aliás a pessoa que me fez conhecer a pessoa mais fantástica do meu mundo...

O anel

Tirei umas fériazinhas dos desenhos. Estava planejando segurar mais par a publicar tudo juntos mas percebi que isso so ia fazer tudo demorar mais. Vou contando no meu ritmo mesmo

‹1 / 2›

A surpresa 12 – Aterrisando

Eu quase peguei aquela florzinha azul!.. Quase.. :(

a surpresa 13 – indo pro brejo

Nessa hora eu estava seriamente pensando em todas as outras coisas românticas que poderia ter feito com a Fê que não envolvia estar em um charco..

a surpresa final

Clique pelas setinhas para uma experiência mais divertida...

‹1 / 18›

E eles responderam basicamente "te entendemos, não concordamos com isso agora, mas vamos te dar todo o apoio que você precisar"

Leio (ou nesse caso ouço) alguns livros que me deixam pensando muito tempo. Quase todos os do Steven Johnson ou Malcom Gladwell caem nessa categoria, pois são livros de não-ficção estruturados como uma ficção. Ghost map, especialmente é um livro que daria um filme, de tão bem que ele amarra todas as histórias em uma trama central e um cenário rico. Decidi então desenhar a minha recomendação de leitura. É também um ótimo exercício de storytelling resumir tudo a no máximo nove quadros por página, e me trouxe algumas exigências de desenho um pouco mais complexas...

Se você olhar direitinho, deixei no canto em branco os rascunhos que fiz do rosto. Esse desenho deu mais trabalho

alguns dias são difíceis de serem explicados em imagens ou palavras. Mas se você entender só o finalzinho, então é universal...

todo dia eu vou treinando um pouco, parece que vai voltando alguma coisa...

Neutral milk hotel e feist me ajudaram mais a terminar o trabalho. Mas a idéia até agora ainda me fascina...

Não vou contar como eu saí dessa. Mas não envolveu pedir dinheiro na rua nem telefonar pra ninguém..

but someone should.

"The children and staff are safe, though they have only enough food and medicine for about a week. The markets have been closed in Port-Au-Prince, so this could become a concern. Emile said earlier today that he feels things will get better soon because of the peacekeepers.

Everyone's taking it day by day. I just got off the phone with Emile, our chief mentor in Haiti, who is staying in the countryside until things come down. Our pilot is effectively on hold due to safety concerns. I'll update you when I hear more about the children, who are close to the area of the protests."

This raises two important issues on the Haiti Pilot. The first is one that was brought before by Wayan: OLPC is an education project, but there are maybe some places that are beyond the reach of the One Laptop goal. It seems that the riots are calming down now, but what if they did not?

If violence in Port au Prince escalated to a point where most family would be forced to flee to surrounding areas, what would happen to the pilot project? Would the families disperse and the valuable laptops quickly vanish from the kid's hand as they where forced to sell/give it away? Or would Waveplace Foundation grab all the laptops from international donors and move out of the country, or risk having the school looted to bare bones?

Maybe we have to wait until political stability has reigned in some places, before a long term education project can be invested. Maybe it's too much risk for those precious resources that could be more safely invested in quiet rural areas in Peru. Maybe the "Mudhut argument" is true and laptops serve no good for kids below a certain threshold of poverty, that lack more basic things such a peaceful environment in which to grow.

Or maybe not, and that's the second important issue on this. Watch this footage sent us from Haiti:

Although it has CNN stamped on it it's clear that much of those videos are made from amateur cameras. We are talking about impoverished Haiti, all right, but we are talking about a 21st Century impoverished Haiti and they are also part of the digital imaging generation, and those in the middle to upper class in Port au Prince can afford some way to film video and post it online.

None of them are actually coming from kids with XO laptops, but - hey they could be. We are all shocked hearing those reports of violence from Haiti, but maybe if there were no computers anywhere we might never hear them in the first place. Thanks to this connecting technology we can see the San Francisco Olympic torch protests live on the web, we can see the violence in Zimbabwe in Google maps.

And thanks to a mesh system this communication network might still work if everything else goes down. So giving the impoverished kids of Haiti a way to allow their voices be heard, their stories be told and allowing them hearing news from the world outside even during a crisis is a way to be a part of this new generation.

And maybe this is worth all the risks.

Medidas preventivas foram bem sucedidas nos últimos cem anos, mas existe um risco crescente que elas falhem em algum ponto nos próximos 5 mil anos

Partindo do pressuposto que uma das milhares de opção de apocalipse se realize dentro de dois ou três mil anos, é importante ressaltar que esse tempo, apesar de longo para uma vida é relativamente irrelevante em termos evolutivos ou mesmo cosmogênicos.

Percebendo que o tempo, na escala cósmica entre o surgimento da vida e seu auto aniquilamente é quase um estlo imediato, notemos que é um tempo muito curto para que possamos mudar de galáxia ou criar um novo planeta.

Conclusão:

A vida nesse exemplo é como faíscas que surgem espontaneamente em um matagal onde cada plantinha está separada por dois mil kilômetros de deserto.

Do ponto de vista cósmico, Vida é uma anomalidade planetária autodestrutiva de curtíssima duração.

C.Q.D.

Mas o blog não morreu nem morrerá. Tenho o que dizer e sempre que quiser dizer o farei por aqui. Decidi tomar a pílula do RSS que alivia o autor da necessidade de constância. O dia que eu colocar algo novo, deixe-mem que eu mesmo aviso.

Agora seguimos com nossa programação normal..

If there's a trend that is universally welcome is the greener technology trend. But in most industries green is sold at a special premium: from organic food to electric cars, you are paying for your eco-conscience. But Mary Lou Jepsen has different approach.

At first when told that to go green would be more costly the OLPC was willing to sacrifice a greener XO for a cheaper but not so green laptop. But as she progressed on the design process it became clear that to build a laptop that cost less also means a laptop that consumes less resources as a whole. In her words:

"People are trying to make a buck off of green. Green is actually cheaper. Green isn't about (sigh) buying more stuff."

According to a very inspiring keynote she gave at the Greener Gadget conference in the beginning of February the factors of making a laptop green are:

• Consume less power. According to Mary Lou if every computer in the consumer market had the power footprint of the XO, their total energy consumption could fall 95%. Also by reducing the necessary power it needs to run you put the laptop under the threshold that can be provided by some clever and surprisingly low tech sources, as cows, bicycles or cheap solar panels.

• Expand the lifetime of the product. Surprisingly enough that's a factor rarely factored in when figuring out the impact of a product: how long will it last?

• Repairing is more important than recycling. If disposed the XO battery can be "consumed by soil bacteria" but Mary Lou has a bigger point: by making the laptop easier to service will prevent it from being dumped in the first place.

You can check the highlights of the presentation above, but I would highly recommend anyone actually watching the whole 50 minutes presentation where she talks a bit about the purpose of her new company PixelQi, the deployment of the laptop and the history of the design.

Or if you attended you could have done as Crackhead did and actually get Jepsen to sign your XO.

Em quase todas as empresas de web que já trabalhei houve um mesmo momento, já participei da discussão sobre uma mesma página central: cadastro. Se cadastrar é tratado como um mal necessário, uma retribuição que o usuário faz ao site “fizemos o site todo, o mínimo que ele pode fazer é nos dar o seu email”.

Espero que essa seja mais uma mentalidade que mude logo. Hoje há dois caminhos básicos para um site login-free: você cria ele como um anexo de uma rede social já existente, (api do twitter, facebook apps ou opensocial) ou você usa um cadastro universal decentralizado (openID) onde o usuário se identifica com uma url.

Nenhuma dessas tecnologias ainda é perfeita, e talvez no futuro surjam mistos interessantes, mas elas são absolutamente necessárias. Por que?

1- Os usuários querem. Já passamos do ponto de saturação de redes sociais. Pedir que eu convide meus amigos para o seu site é me convidar a passar longe.

2- Honestidade. Para muitos sites confiáveis, ter um email checado e informações extras tem um enorme “valor em mailing”. Seremos sinceros: mailing é uma forma disfarçada de spam. Revender essa base é retirar o disfarce.

4- Acabar com os muros entre os sites. Se você pode participar de um site se referenciando como outro os sites tomam vida própria. Torna-se possível ver –literalmente– o que um site ou companhia diz ou faz no outro criando uma conversa real entre eles.

5- Dados atualizados, sempre. Ter uma informação sobre mim sentada em um único canto controlado por mim garante que ela vai estar atualizada e completa.

6- Reputação. É muito mais fácil identificar a reputação de um usuário que já tem um histórico em outras redes do que quando tudo que temos é um username.

Last Friday the Brazilian Government nullified the December laptop bidding that was partially won by Positivo Informática with the Classmate PC laptop, alleging the final US$360 per unit price was too expensive.

Although it never published what was the reference price it expected, some government officials have compared to the US$199 Uruguay paid for each XO Laptop unit. SIMM, the company with the exclusive distribution of the OLPC in Brazil had offered the XO for US$387 a price that David Cavallo said it was the minimum they could offer at those conditions.

And the auction conditions were in fact very different from Uruguay so the price comparison is almost unfair. For one, Uruguay centralized all shipping to one location and distribution would be done by the government.

In the Brazilian case laptops were to be shipped to different states in almost continental sized country, including some Amazon states that are only reachable by air or river. Other key differences go in the three year warranty that the Lula Government asked and finally the import tax breaks that were promised but never delivered.

At the moment the future of the Um Computador por Aluno (One Computer per Student, in Portuguese) laptops is uncertain. Brazilian Newspaper Folha speculates that the next bidding might have fewer requirements, ask for fewer laptops or finally increase the allotted money.

In the last month, the OLPC Brazil community hasn't stopped analyzing the meaning of the Classmate partial win of the now-cancelled bid. Some highlights:

• Although many have accused Intel of dumping the price of the classmate to win over the XO, this possibility found more ground in the hearts of the conspiracy theory believers than in the math of any rabid OLPC defender.The lower price by Positivo was achieved by more clever business tactics, knowing the Brazilian tax reality and doing local assembly. Positivo responded by saying that they are ready to get the price down to US$300 if some tax-breaks apply.

• An interesting fact has emerged: when adding all the 4,000 hours the laptops are expected to be used, each XO laptop is expected to consume US$45 dollars worth of energy, while the more power hungry Classmate would consume US$90. It's a small difference but in such a tight race, 45 dollars can tip TCO calculations to the other side.

• Before the auction took place every hardware manufacturer was complaining for some requirement that should or should not be, which of course always coincided with something that their own product would have. One of the most intriguing was a complaint by the Telecomm industry on the requirement of Mesh Networking. The fact is that some Cell phone carriers were willing to offer phones as tools to bridge the digital gap. On a pay per minute basis, of course.

• The most expensive offer was done by no one other than Sony. This Japanese company was willing to equip every Brazilian student with a feature- full Sony Vaio for the modest fee of over 1 billion US dollars.

In related news, the teacher Léa Fagundes, responsible for the Brazil pilot project was just awarded a Unesco Prize for her works on technologies in education. The award was given (along with another for the singer, songwriter and Brazil's minister of culture Gilberto Gil) in a special event held to celebrate Unesco's 60 year anniversary..

Ten years ago, a cd burner was something expensive, few people had heard of USB connections and the keychain flash drive wasn't coming to market for another two years. This move was considered highly ahead of it's time for apple and for some this helped launch the USB as a standard and displace the 3.5" disks onto oblivion.

Fast forward to 2008 and Apple announced the wireless Macbook Air, a ultralight low power laptop with no cd or dvd drive, no hard disk, but highly connected portable computer. In a few years this will probably be the industry standard, but this time around it's not Cupertino who's setting it.

Granted, one cannot compare the $199 XO to a $1,799 Macbook anymore than one can compare the recently announced $2,500 Nano Car by India's Tata motor to a $50,000 Porsche, unless on technological grounds. And that is what I'm going to do.

Apple Macbook Air vs. OLPC XO-1

By using cutting edge technology, the Negroponte's team was able to come out not with a dumbed down version of a commercial laptop but a innovative product that was also cheap. The XO was the first portable rely solely on solid state drive and following it's steps came the classmate, the Eee pc and now the Macbook Air.

The XO stills sets some standards that are sure to be followed by the big players. The screen technology for example is certainly – as Lou Jepsen has said – to become a trend. The Apple iPhone is probably the only other product that can be compared in terms of screen resolution and I would not be surprised if their laptops upgraded to 144 dpi displays soon.

And I could bet that mesh networking is the next XO technology to come to a general consumer product. Of course this is not to say that other industries are copying the XO innovations but this is rather a consequence of bigger trends (like falling flash drive prices) that OLPC happened to catch first.

What this does means is that probably all this incredible "clock-stopping hot" technology the little green laptop has today will probably be quite common place by the end of 2008. And by then, what will happen to the One Laptop?

Price vs. Power Future

By there we can expect Apple, Eee, Dell and every other computer manufacturer to have updated their computer models. Prices may go down a bit, but muscles will surely go way up. What can we expect from OLPC?

I hope XO2 to continue forcing the biggest innovation on the computer industry so far: that muscles might go up a bit, but price – oh price – will continue to drop radically.

Let all the computer manufacturers continue their Arms Race. Let OLPC step outside to another completely different kind of marathon.

The one for the children.

web 4.0 vai ser quando toda a informação estiver bem organizada, todos os metadados estiverem completos, todas as redes sociais estiverem saturadas, todos os artigos sobre o assunto forem escritos, a internet se desintegrar em oxigênio, o browser se tornar desnecessário, e pudermos, finalmente, seguir em frente com as nossas vidas nos preocupando com outras coisas mais relevantes.

Eu desejo um 2008 com menos hype e buzzwords e mais conteúdo para todos vocês.

The Brazilian auction to purchase 150,000 computers for children is on currently on hold after the end of the first round which ended on December 19th. Positivo Informática won the first round of biding with the lowest offer, 98 millions of Reais, 6 million less than OLPC had offered.

No one has had access to details of each proposal but the most probable culprit were customs duties in Brazil which, along with all the maintenance and warranties, brought the total of each XO to $387,39, twenty dollars over the winning model. Positivo had by it's side decades olds tax policies that favors local assembly with lower taxes on electronics components, not ready made equipment.

The model offered by Positivo is still unknown but Intel has already congratulated them for winning, which led all to believe that it's a newer version of the Classmate PC with built-in camera and mesh networking.

To bring yet more confusion to the issue, in the same morning that the auction began was issued an official statement freeing all candidates of the taxes, but no one, neither the candidates or the auction judges, were informed about it.

Currently the fate of the 150,000 laptops are unknown. The judges consider the price high but the rules allow exclusive negotiations with Positivo Informática - the lowest bidder.

Jaime Balbino, a fervent OLPC supporter made an interview with David Cavallo, the main representative of the OLPC in Brazil. They talked about the influence of Brazil in the development of the model advocated by OLPC, the Brazilian development policy, competition against monopolies of technology, the bidding (won by Positive Computing) and the future of the entity without the expansion of the Brazilian experience.

From Jaime's interview:

Local assembly: the key to BrazilDavid Cavallo: I personally believe that things went somewhat astray for a variety of reasons and that the structure of the governmental purchase request led to a result no one seems to be satisfied with.

We are a non-profit. Our price to any country, including Brazil, is the cost of the laptop itself. Uruguay purchased the laptop for USD$197. They also purchased in a way that brought connectivity to homes and communities. We will not bid above our costs. We cannot bid below our costs, as a for-profit might do in order to make profit by charging more for other products and services, or to lock out competition and raise prices subsequently.

So the huge price differential was because of the extraneous conditions imposed upon price for the bid. This includes local assembly (NOT PRODUCTION OR FABRICATION, for which conditions do not exist at this time in Brazil), various taxes, shipping (of components which also raises costs), and a 3-year warranty. They also decided to select solely on the basis of price, without consideration of the display, or power consumption, or eco-friendliness, or connectivity in and out of schools."David Cavallo then reminds us that the project can go on, with or without Brazil as they have already enough buyers to make it sustainable.

For OLPC in Brazil, the game doesn't ends until the judge brings the hammer down, and the last message from the auction site was that the bid was closed for an indeterminate time.

If we do not hear from them today, we will probably not hear anything until after the Christmas holidays are over. Or worst, we might have to wait until the new year begins because, as a local saying goes"in Brazil the year doesn't start before the carnival ends."And by then, it might be just too late.

Tags: Classmate PC | Custom Duties | David Cavallo | Jaime Balbino | OLPC | OLPC Brazil | Positivo Informática | XO Laptop |

A lixeirinha que voce joga coisas fora, assim como as pastas as janelas e icones da área de trabalho, já fizeram 20 anos de vida O mouse com que você mexe tudo isso já passou de muito disso. 2007 foi definitivamente o ano que produtos com interfaces totalmente diferentes chegaram ao mercado mainstream mostrando que outra interação é possível e que ela vai além do nosso computador pessoal.

<iPhone e seu Multitouch. Touchscreen já existe há duas décadas, mas era tão natural quanto tentar arrumar seus papéis com um dedo só. Poder usar mais de um dedo significa poder girar a mão, apertar, soltar. E adicionar elementos de física, inércia, desaceleração para os elementos da interface são mais do que uma animação decorativa, tornam tudo mais natural. Que 2008 as interfaces pareçam com elementos do mundo real.

Wii e seus vários sensores. O wii tem tantos sensores que fazem você esquecer que ele tem quaisquer sensores. Jogar com ele é usar a imaginação e brincar sacudindo sua espada invisível, apontando um arco e flecha não existente. Que em 2008 interfaces levem mais em consideração o objeto como um todo e sua posição no mundo real e não só os botões que você aperta.

Google Android. A plataforma open source para celulares do google parece já ser campeão antes mesmo de existir. O iPhone só se tornou realmente útil depois que fo hackeado com novos aplicativos. Quem em 2008 plataformas sejam abertas.

XO e o sugar. Claro que não podia deixar esse menino de lado. Apesar de usar a mesma interação básica: teclado e mouse, o Sugar se destaca imensamente por ter toda uma nova metáfora da computação emprestada da web, onde tudo gira em torno de colaboração. Que 2008 possamos aceitar e aprender novas metáforas para nossos sites e softwares.

Yesterday was the first day of the auction process for the Um Computador por Aluno project (One Computer per Student, in Portuguese). The process was suspended at the end of the day inconclusively and can drag for two more days.

The lowest offer was at 71.2 million dollars which prices every one of the 150,000 laptops at US$475 which was deemed as unacceptable by the house. Over 8 proposals were made from prices ranging from $500 to $1,600 dollars, but the identity of all bidders will be revealed only after the auction is over.

The whole process is being very open, and this was embraced wholeheartedly by the open source community which followed the auction site as if it was a twitter account. All bids and messages from the judges are posted online and can be followed by anyone with an internet access and every half hour updates were posted to multiple OLPC related mailing lists.

From there they where dissected as everyone tries to make sense of what, in the end, makes the price of one laptop. And finally all price changes were documented in an online spreadsheet that also converted the prices from Brazilian real to US dollar.

The price of US$475 ( R$855 ) include shipping, maintenance and taxes, lots of taxes. In Brazil all electronic imports are charged at least 60% percent over their sales price just to cross the border. Take in account other duties, including sales and that`s the reason this is the leading country in the international iPod currency index.

This contradiction, where the government cannot afford to pay its own taxes where previously known and led to some Government officials to declare their intent on making the educational laptop duty-free. Nothing official was arranged before the start of the bid which led the bid judge to clarify that all taxes should be taken in account. The taxes could be lifted later for this or future purchases, bringing the total cost to considerably lower.

If OLPC win this game this might mean much more than 150 thousand laptops out of quanta. The UCA project main goal is to achieve a total annual order of 12 million laptops. The process will end in the 20th but government official said the result can be published as late as the 24th.

Will OLPC find a 150 thousand present wrapped under it's Christmas tree?

Essa é a minha receita. Aceito sugestões.

1-O design em si, ninguém escapa do photoshop..

2-Instale o Quicksilver. É a cola que junta tudo.

3-Abra uma janela do preview com o design.

4-Para acessar e mesmo editar arquivos direto do ftp: Cyberduck.

5-Configure o CSSEdit como editor externo de CSS no Cyberduck. Este é um dos programas mais bem feitos que já vi.

6-Usando o quicksilver chame o Xscope. Um programinha hiper simples com uma série de ferramentas como réguas, lupas e guias para voce colocar por cima de qualquer janela.

7-Use Backdrop, o 2o programa mais simples do mundo: uma tela preta pra tapar as outras janelas.

8-Se você tiver uma tela grande (ou dois monitores) pode colocar o preview e o css edit lado a lado e ir copiando usando essas réguas o layout literalmente pixel por pixel. O css edit ainda usa o colorpicker do OS X que permite que você puxe para seus elementos exatamente a cor que estiver em qualquer janela.

9-Para editar os htmls eu uso o Smultron que é opensource e faz o básico de um notepad. Graças a comunidade já fizeram até mesmo um set de ícones melhor para ele.

10-Poderia continuar listando: Colorschemer, Disco, Growl, Galleria

Brazil's UCA Laptop RFP

As the law mandates, the RFP is open for anyone to bid in, but the way the official solicitation is written it becomes clear they already have a winner in mind. The bidding demands that the laptops must have:

• A gnu-linux operation system

• A video camera, microphone and audio output

• Support temperatures between 5 and 41 degrees Celsius

• A screen at least 7 inches, a minimum 800x600 pixel, not too much reflective on highly bright areas and have a high contrast in dark places

• And the ability to mesh network with one another

If that does not fit the XO laptop description enough, the final winner will be chosen based on who comes with the lowest price. Proposals will be accepted between December 18-20 so if Intel wants to be in the game they have no more than a week to have a serious update on their screen and a mesh network capability.

There's only one requirement that may make One Laptop Per Child sweat: the laptops must have a minimum of 36 months of full warranty. That's far from the naive "kids will repair it" maintenance plan of OLPC, but is in line with the Brightstar promise to OLPC Uruguay.

Equal Distribution

The laptops are intended to be distributed in 300 schools throughout all 26 states of Brazil equally, independent of state population. For a contrast 4,600 thousand laptops will be distributed in the Amazon state where the total population is 3.2 million while São Paulo with it's population of 40 million will receive only 5,500.

Brazil is a country of over 180 million people with at least 8 million kids aged between 5-9. Just 150,000 might seem shy when compared to the 250,000 of Peru or even 100,000 for the smaller 2 million habitants neighbor Uruguay. But seen as a whole it seems that South America is seriously intending to be the forefront of OLPC for 2008.

And here is a preview of what Brazilian teachers might experience soon, when laptops start to invade classrooms. Professora. Tania da Escola Luciana de Abreu Fala in Luciana de Abreu School, Porto Alegre speaks about OLPC Brazil in her classroom:

Translated video from OLPC.TV.

Bonita. Cores vivas, e uma Vag rounded bonita. Mas o que é? Uma compania nova de celulares para concorrer com o mesmo público da oi? Um novo serviço de telefonia fixa? Um voip phone? No fundo eles perderam a maior da platéia nesse ponto que tem coisas mais importantes para fazer no metrô como ficar ouvindo a nona de bethoven em loop nos alto falantes.

Sabe qual é o agravante? Que a porcaria do produto, funcional, real, táctil estava a 10 metros de distância de todos! O produto em questão é um telefone móvel para ônibus que você utiliza com um cartão telefônico comum. Eu sei disso por que tive um amigo que trabalhou no produto, por que sou curioso o bastante para ficar mexendo nos aparelhos misteriosos que aparecem no ônibus e por que procuro respostas no google quando chego em casa. Quantos outros passageiros são assim?

Mesmo na comunicação de “instruções” (colada no aparelho pequenino) não comunica o essencial: quanto custa?

A propaganda sumiu dos metrôs desde então, junto com o aparelho. Espero que eles não tenham levado em conta a utilização do telefone nesse teste piloto (zero, suponho) para pautar o futuro do produto – que, torço eu, seja um sucesso.

Em seguir a minha sutil sugestão para a comunicação (desculpem a falta de vag rounded).

A comunidade em torno do Papervision é tão ativa que quase não recomendo a ninguém assinar a mailing. No fundo a promessa, interatividade 3d, leve e acessível em todos os browsers, atrai o olho de muita gente.A tecnologia não é fácil de instalar ou aprender, pra começar você tem de instalar um SVN, depois alterar class path nos settings do ActionScript 3.0 e todo os códigos devem ser postos em um arquivo .as externo. Além disso toda a programação e animação no Papervision é feita por código? Pense em 3dMax, Maya ou blender com a interface do Notepad. Nem parece aquele programinha simples pra fazer animações que eu conheci.

Mas talvez isso mude, imagine que por exemplo a Adobe decide integrar isso na próxima interface do Flash.

Quando isso acontecer prevejo uma internet moderna como em 1998: uma febre onde a web será reinfestada de caquinhas de sites comerciais totalmente inacessíveis, animações desnecessárias e navegações incompreensíveis. Sem contar que, simulando 3d através de triângulos e sem acesso a aceleradpres do próprio sistema operacional, a qualidade gráfica está mais para o XWings do que para um videogame mais moderno.

Mas eu tenho esperança: o Youtube pôde surgir por que soube usar o flash para algo que ele faz muito bem, um pequeno objeto que sabe brincar com o resto da internet. Imagine uma amazon com objetos rotacionáveis, um flickr com fotos panorâmica 360, uma wikipedia com objetos manuseáveis. Na internet é importante cada vez mais pensar pequeno.

• Um uso desnecessário: Sony bravia. Você adora os comerciais mas já chegou no site alguma vez? Eis por que não.

• Um uso interessante: Everyscape (veja tb EarthMine)

•

Um uso bom, mas cru: Poly earth

• Um uso lindo: Panorama Ultrarealístico de uma biblioteca

• Demonstrações da tecnologia: Coverflow, Globo de metal, Cavalo Marinho

• Jogos: X-Wings e Quake

• Quer tentar? Então baixe, instale, pegue demos e discuta.

From 10 to 11th November, Sao Carlos, a city in Sao Paulo, hosted the first Brazilian OLPC Game Jam. Six groups of students spent 48 hours, some without sleep, developing new games from scratch to the Sugar platform.

Sunday kids from local schools were called in to the daunting task of playing all the games and choosing a winner, which took home a brand new green machine to continue developing.

The main goal of course was to seed developing of games, no one was expected to have a full complete game without errors, but a playable version that can be further developed. The winner was a game of Pong with a twist: they used the XO tablet mode to build a game for two players each one sitting opposite to each other.

The other games developed were:

• ReciclaPY a circling game with educational purposes. Kids must direct the falling trash to the right basket

• Math Balloon: A math game, were each operation is represented by a color balloon

• War of boots (Guerra das botas): Not much information available, but some kind of Nibble games with boots

But developer's (and this writer) favorite was one overlooked by the child judges: Gambiarra, a The Incredible Machine clone:

The game seems really fun, and a feat to accomplish so much in a short period of time, although in the developer's own word the visual were poor because they lack graphic skills.

But in the end of the day, it still is a clone. In a perfect world other developers would follow the steps of Will Wright and release the source of old games that cannot be profitable anymore to be repacked into new platforms such as OLPC.

"The Incredible Machine" was a product of Dynamix Entertainment, released from the early to mid 90's. Dynamix was bought by Sierra which due to a series of twists is now today a failing arm of Vivendi. Just to sort out who owns the rights to the original TIM game would be more costly than anyone in the company could bother to care.

In the real world, most of those games will end up in the XO platform through some MS DOS emulator hoop, which is barely legal and won't allow innovation as future developers improve the code. Then if developer wants to bring to today's kids the joy they had with computer games the only thing they can do is rebuild it from scratch. In our imperfect world, kids learn from a early age how to jump through legal barriers.

As one Game jam developer described, after playing the game a child replied: "Great! Will you release a pirate version of this?"

"Vatican officials, ambassadors to the Vatican, and representatives of the world's religious orders were among the more than 200 people attending an Oct. 29 conference highlighting the One Laptop Per Child initiative. The conference was sponsored by the communications office of Rome's Jesuit headquarters and two commissions of the international organization of superiors general of religious orders."

The connection should not be as unexpected as it might sound. The Jesuits have, since their inception, sponsored schools across the globe, and involved in missions in the poorest corners of the world. Religious orders have for long known that education is a key to the survival of their beliefs onto the next generation.

Education First

I am Alexandre Van de Sande, an interaction designer and a shameless OLPC fan-boy. And as an Agnostic raised inside an Augustinian School I can attest: it's about education first, Christianizing later. The age of Jesuits roaming the world converting natives is over, and "education first" is the only win-win strategy. Religion sponsored education has already graduated millions of children worldwide and for most part this does mean quality education with real science: the phenomena of creationism bogus infiltrating some north American conservative schools tends to be an exception to the rule, and one can only hope that it can be entirely left out of this debate.

Also the Society of Jesus order (as they are known in the Catholic Church) have historically been early adopters of advanced ideas before the rest of the Roman Catholic Church. In the 17th century they were the first to try to debate in scientific – not religious – grounds with Galileo on the phenomena of Sunspots, and in the 19th century South America they were among the first Europeans to defend the native Americans from colonial slavery.

Although the Vatican is a country, a Pope-sponsored OLPC program is more akin to a NGO jumping in the band wagon, which shows one positive consequence of reducing minimal laptop orders to 10,000, 1,000 or 100. As such they have many advantages in place that the OLPC organization might never have: a far reaching distribution network around the world, an established curriculum, teaching infrastructure and perhaps the most important, experience in continuous fundraising. The XO laptop would do what it does best: be just another piece of the education puzzle, not a ready made education revolution in a box.

Sugarized Local Religions

Beyond the dangers of proselytization, Sugar can be very powerful to local religion and cultures. It's focus on the local network first and the internet later helps keeping the child under the sphere of influence of their own community, and the camera and mic can be used to record and archive traditional prayers and rituals.

Finally there's a final twist: One thing is to build an interface that is usable by children – kids can learn anything they put their minds to – but another completely different is an interface that can be used by adults with a more traditional mindset.

I believe not only that Sugar can hold to the task but I would go further and say that because of some of it basic principles – like the abandonment of the office desktop metaphor, the more humanized icons and the tablet that allows handwriting in any alphabet – that the OLPC will benefit immensely from their feedback. The XO doesn't require much learning or wasted hours of installing a de-installing applications, cleaning the system and learning a whole new tech vocabulary.

Because it's an open platform, it can be very easily adapted to user's needs. The humans using it won't need to change drastically the way they think – their culture – while the machine is able to be adapted to their lifestyle. We want the OLPC generation to use computers to learn about the world around them, understand their own history and reinforce their own identities, not create a new generation of western computer geeks.

Those last two points were the theme of my graduation thesis about interaction design, which became the short video documentary below:

.

OLPCNews one classroom at a time campaign from alexandre van de sande on Vimeo.

Acredito que a solução de boa parte de nossos maiores problemas passa necessariamente por educação, informação, comunicação e colaboração. Em permitir que qualquer um registre o presente, lembre do passado e lance sua mensagem.Acredito que a tecnologia é capaz de dar alguma dessas ferramentas ao todos.Por isso quando em 2005 o cérebro por trás do MIT Media Lab, Nicholas Negroponte, anunciou que iria se dedicar a criar um laptop por um décimo do preço dos atuais e esse seria voltado para as crianças do mundo, eu me tornei um grande defensor. Ultimamente me envolvi como colunista para o OLPC News a maior referência de notícias sobre o projeto e ainda mais recentemente me envolvi em um projeto mais interessante ainda.Equipar uma sala de aula.

OLPC News 100 laptops fundraising

Hoje, na OLPC News iniciamos uma arrecadação de fundos para encontrarmos 200 boas almas que contribuam para a compra de 100 computadores para as salas de aula do 3o mundo. Ao mesmo tempo, estamos procurando escolas que queiram ser a receptora do projeto.Então se você tem amigos em qualquer lugar do mundo que queiram ser um desses patronos, por favor passe essa mensagem adiante.Se você tem um conhecido que trabalhe em uma escola com cabeça pra frente mas precisando de equipamentos, no Brasil ou lá fora, que poderia se tornar uma recipiente desses computadores, também mande essa mensagem adiante. Diga-os para entrar em contato comigo.

Acredito que a internet importa mais que meu blog, que o teu blog ou mesmo a soma dos dois. Ela importa como idéia. E idéias, são a única coisa que mudam.

Let me explain with a video:

Technology is one tool that can help do that. That’s why I have always been a believer in the power of giving access to computing power and to the internet to the more vast array of people possible, and that’s the main reason I support the One Laptop Per Child program. Now that OLPC has made the Give Many program easier to participate in, I have an idea that Wayan Vota and I want to share with you.

We are proud to start a fundraising to achieve the modest goal of equip one of the local initiatives we’ve been reporting for over two years. We present to you:

OLPC News 100 Laptop Fundraising Drive

Let's raise $20,000 in donations for one hundred XO-1 laptops to be sent to the best locally-organized OLPC learning club!

Donors

1. Pledge at least $100 on the OLPC News Fundraising Drive site

2. If/when we reach $20,000, vote for the best program to get 60-100 laptops

3. If we don't reach $20,000, then everyone's pledge is nullified and we just watch others Give Many.

Local Programs

1. Organize a local OLPC learning club in your community

2. Send us a post on how you'd use 60 laptops to enhance education

3. If you win, pass out laptops with a smile

Now don't think we'll be passing out laptops to just anyone. Each local initiative will be debated on OLPC News based on what are the concrete realities and how well established is the curriculum implementation, power grid and internet access on each pilot.

After the vote by the donors, the winning group will get our 60 directed laptops, and we will ask OLPC to direct their 40 laptops to the second place group.

Everyone

If you can't donate you can help our cause by spreading the word around, from re-blogging the video to Digg ing it, to adding it to del.ico.us, Stumble On, Slashdotting it, to posting this page on Facebook

About the XO laptop:

First presented by M.I.T. Media Lab founder Nicholas Negroponte in 2005, the once called US$100 laptop is a fresh start in computing. This is the electric car in a world of SUVs: instead of trying the biggest faster laptop around it's the one that does more with less.

It can connect to other similar laptops without a connection to the internet. If it finds a hotspot it can stretch it to other computers without being turned on.

It allows you to read a book or a site on the screen without consuming any power (while being virtually a sleep). It runs for less energy, cost fewer dollars, immune to computer viruses and lasts longer even in the hands of children.

Did we mentioned that it's also water and dust proof, can be readable on sunlight and has a revolutionary but easy to use interface?

Also it's not about doing spreadsheets: it comes with free software for music making drawing, blogging, filming, taking photos, making interactive games, doing stop motion animation, a full encyclopedia, a ebook reader and lots of games, including SimCity, the original.

About OLPC NEWS

Started by Wayan Vota in 2006 OLPC News prides itself on being an independent news source for all things related to One Laptop Per Child. OLPC News is now a community of more than a dozen regular contributors writing daily about OLPC and its impact on education and technology.

OLPC News is so informative and influential, it's referenced in international media, including an appearance on CBS News' 60 Minutes. OLPC News is not affiliated with the One Laptop Per Child organization.

Então decidi começar um blog. Mas será que esse mundo precisa de mais um blog? Precisa. Precisa de mais seis bilhões de blogs. Cada pessoa no mundo tem uma história pra contar que vale um filme. Mas isso não é um apelo social dizendo a quantidade de pessoas no mundo que não tem voz, é só um lembrete que acreditar que só vale falar algo se você for o mais ouvido, que a internet é uma competição pelo primeiro lugar, que dizer coisas per se – e não o que é dito – é uma profissão em potencial, você está ignorando não só a estrutua da internet, a cauda longa, a consumergeneratedmedia e tantas outras buzzwords. Você está ignorando a regra básica de viver em sociedade que seu avô aprendeu na pré-escola: para cada duas orelhas do mundo, existe uma boca pra responder.Então esse éum lugar para dizer o que penso – e que creidto não estar sendo dito – para uma meia dúzia de primatas.Mas vêm com algumas regras, por que por exceção de amigos pessoais, não leio nenhum blog que o autor o defina como “sobre o que me vier a cabeça”. E limites ajudam a criatividade.

1. Cada post é sobre um assunto e o ponto tem que ser algo que você possa concordar ou discordar, mas que chegue a algum lugar. Se eu tiver outr assunto que isso fique pra outra discussão.

2. Os posts deverão ser relativamente curtos. Algo como 140 ou 200 palavras. O número exato ainda será definido.

3. Dessas x palavras uma será obrigatória. Vou adotar uma palavra para mim, de preferência uma complexa como “esdrúxulo” ou uma degenerativa porém educada como “cocô”, ou m verbo como “descascar”. Sugestões são bem vindas.

4. Os posts serão semanais. As vezes posso escrever um segundo na semana e esse pode ser bem mais simples, mas vou tentar escrever no mínimo um por semana

5. Nada de relinkar para reportagens. Gosto e leio de alguns blogs que fazem nada mais que repassar adiante notícias, mas não ouso achar que eu serei o primeiro a saber de uma coisa.

6. Cada post terá uma ilustração ou vídeo para os preguiçosos.

E paro por aqui ou lá se vai a minha regra número 2.

You probably know about the Motion Sensors on the Nintendo video game, and about all the multiTouch going on with the apple phone, but do you know why the "$100 laptop" interface experience, called sugar, is radically different from any other operating system on the market? And why not?

Because you don't like the icons. They don't have any eye-candies, do not look 3d, have no drop shadows and no floor reflections. The icons looks childish, the graphics seems like it was designed for a computer with no dedicated video-card and almost no RAM. Guess what – they were.

To fully understand the wonderful work that created the sugar interface you had to see beyond your prejudices (and read a long very technical text or watch a video). This article is a guide to the basics of Sugar user experience, translated for those adults which have been spoiled by years of Mac or Windows use. The underlying principles are the same, but the elements of the graphic user interface appears here rendered as if they were in the Mac OS X Aqua interface:But before we continue, a disclaimer. This is in no way intended as a criticism about the look of Sugar GUI. It would be naive to propose superfluous graphic effects on a very no-frills laptop. Also beautiful interfaces can be made using very simple elements and no colors. Finally, even if the MIT team which designed the interface were to ask for help, they would be better off with the Vimeo Designers than with the Apple folks.

First Principles

Most commercial interfaces were designed originally for office workers wanting to remain undisturbed on their own cubicles. The fingerprint remains, and most windows and macs are still built for single users doing multiple works. The XO laptop was designed to incite collaborative works amongst students. Therefore, sharing files, connecting to friends, P2P downloading of programs, social networking and multiplayer games are not separated applications, but integrated on one experience with the Operating System.

Also the screen – although handling twice the resolution of most conventional monitors – is only 7.5 inches. So all programs run in full screen mode. Again, it's not a computer made for a single user doing multiple tasks at the same time. It's designed so that multiple users can collaborate on a single task.The Frame

The most important GUI element is the Frame. It appears when the mouse moves beyond any side of the screen, or when the button is pressed on the keyboard. The four sides are (clockwise from the right side): persons, actions, objects and places. Or if you prefer: the buddy list, the dock, the clipboard and the menu bar.

The buddy list is sort of iChat meets twitter meets social network, all integrated in your OS. But instead of being a list of online buddies, it displays the friends who are engaged on the same activity as yourself. See all people that are reading the same book, or working on the same report, or playing the same game that you are right now. Mousing over the icons will display a short profile with name, age, interests, class and etc.

The bottom bar is the dock, which work mainly as an Applications Activity launcher and a system tray. Here will reside all the applications he have already on his computer, and also any pending invitation to download a new app join a new activity. All systems messages, appears on the dock, in the order they are received. Because the system is designed to keep the user concentrated on the task he is currently in, those will not pop up automatically, but instead will appear minimized until they are read and the appropriate action is taken.

On any OS the clipboard is an essential feature that everyone takes for granted, so much to the fact that it almost hasn't changed at all over the years. Because sharing files is so important to the XO experience, the left bar works as a multi-slot, always-visible clipboard.

A temporary place to keep objects to be able to move between activities, on multiple places (see below), or to the bulletin board (which will be explained later). Everything that is copied with the usual keystrokes appears on top of the objects bar, but they can be also dragged in or out directly from web pages, from documents or any other application

And finally on the top you have the menu bar or better referred to as Places bar – since there are no menus on it. At the far right there is the Dashboard Bulletin Board and the spotlight global search field both of which will be discussed later. On the far left, there are four icons which stand for the aforementioned Places. The XO was is designed to be used in many ways, ranging from privately doing some work, to doing it on a selected group or in an open environment where everyone is invited. It's on those icons that you set those preferences.

The Places

Unlike most systems, the privacy/collaboration settings are chosen even before launching an application. Every application activity on the XO can be launched initiated at multiple places, depending whether you want to work privately or with friends, and which ones. If you start an application on your own home, you will be working on it without anyone knowing, but if you start an application on a friends group or on the neighborhood you are implicitly inviting anyone on that place to join you.

Neighborhood

The most broad sharing level is Neighborhood. Every icon represents one XO laptop that is detectable on your mesh network and what activity (if he allows it) the user is in right now. This map represents multiple things:Your state of connectivity: as every laptop also represent a router that extends your wireless connection, the more icons you have on the screen the more reliable you connection will beThe social interactions going on. Here you can see at a glance all the people that are on close to you and which activities they are doing right now. It's like coming to a party and seeing a bunch of friends gathering in multiple circles, around the fire or around a guitar.A peer to peer distribution of applications. Every task you see active represents laptops running a program in sugar, even if you don't have this program on your own machine. By clicking on one activity the laptop will download the latest application version available from your peers, install and run it for you.All sugar apps are portable, which means that by installing or uninstalling an application you are in fact just copying or deleting one file. And thanks to the bitfrost security, all programs are restricted to a closed sandbox with no special permissions (like copying itself or snitching data) making spyware simply unfeasible.What this map does not represents is the physical localization of the kids. You cannot tell simply from mesh connectivity how distant someone is. Some of your friends will be visible even if they are connected to your network through the internet, so an icon here may represent anything from a few meters to thousands kilometers away.

Groups

The next zoom level is you Groups. Here you can see only who is on your friends list and what they are doing now. Again all activities that are on this group represent a implicit invitation for you to engage in.

Instead of highly restrictive and always breakable, the digital parental control which allows or disallows certain applications relies on a very low tech social supervising.

A teacher or a parent on the network cannot tell what every kid is doing with their laptop. But he or she can tell what he is not doing. All collaborators to a project are visible, and all laptops on the same Group can be viewed if they are engaged in something on this zoom level. If a student – or more than one – is not doing what they are supposed to be doing, this will be apparent, much like a teacher in a class can see which students are sleeping, playing or simply just not paying attention.

Also the groups restrictions are very loose in order to leave space for natural social dynamics. Anyone in the group can invite more members, and everyone else will be notified and introduced to him (as a minimized alert on the system tray bar).

Home

The Home level is the computer itself. This is also the most private starting point, and all applications activities started here will be invisible on the network until the user drags it to another broader level. Observe that the default behavior of Windows and OS X, is no more than a special case on the Sugar experience.

The central ring is at the same time a task switcher and the Activity Monitor, where one can see which applications are running and how much memory they are using. Every application running will appear on the circle, filling an area proportional to how much memory it uses, and when the circle is full no new applications will be allowed to run before you close some. Dragging any app from the Dock to the Ring will launch it, and dragging it out of the ring will quit it.

The XO memory is scarce and this allows any children to understand visually how much space is left and to easily identify the memory suckers slowing down the system. Something many other OS'es could use.

Application

The main function of all Places is to help the users engage in Activities. But when he finds one, he will go to the Application Activity level. The place the activity was set reflects whom he will be collaborating with– either only with himself, among his friends or with the whole neighborhood. At any point the privacy level of one document can be changed, but this will reflect only on his own copy. Therefore, one can pick a copy of the current work and take it "home" so he can work on it by himself and only later share with the group. Or one can share that document with other groups or a bigger neighborhood.

But how documents are shared? Where are they saved? Where is the file explorer app? In the next part of this post, we will explore how the Bulletin Board – a Dashboard to share files – and the journal, where all the old metaphors of office automation, saving and archiving files are replaced by a more modern, almost blog like way of organizing your data.

Hello I am Alexandre Van de Sande, an interaction designer currently based in Rio de Janeiro, and in this first article I want to address a fundamental-in my opinion flaw in the OLPC strategy: distribution.

I don't think the One Laptop Per Child as a whole is doing well, there seems to be no government buyers, the production is being constantly postponed and the XO's newest price is around US$200.

But is it really a two hundred dollar laptop that is being sold? At the minimum order of 250,000 computers Nicholas Negroponte is not in the business of selling cheap laptops, but of selling fifty million dollars in untested education reform.

There are of course good reasons for not selling the laptops individually or in the famous buy 2 get 1 scheme: first it's a logistical hell to ship and support. Nicholas Negroponte repeatedly said that half the cost of most laptops were marketing, shipping and support. But most importantly the laptop simply isn't as valuable alone as it's in a group of peers.

It's built up to mesh, to collaborate, to exchange information, to be learned and used within a community of similar laptops. A single laptop when living alone - or worst, when living surrounded by iPhones, Blackberries and Dell machines - becomes simply a cheap toy or an oversized PDA.

But there's a mid ground. It could be sold in radically smaller scale, in 1,000 laptops pack. Then it's not a $200.00 laptop but a $200,000 IT alternative. There are very compelling reasons why it should, maybe even that it must, be delivered that way, and that this decision must be made quick. At least 10 very good reasons:

10. You can't expect the public sector from developing nations to solve anything. Corrupt politicians that expect to get a cut of any multi-million dollar project they vote, slow democracies and short sighted policies: welcome to the third world, Nicholas Negroponte, where the government is part of the problem not the solution.

9. You can't expect presidents from developing nations to keep their promises. Populism is a still alive in South America and Africa as it has always been. It's easy to get any president to pose for photos for the press, specially when they are holding a modern computer that they can promise to give to his people.

But once he on front page, it's over. Populist presidents can see only so far as the next election, and when it comes to invest millions in anything they expect it to be easily understood and remembered to any uneducated voter.

That's why they will prefer to build a unprofitable, incoherent, hand built computer assembly line than to buy any computer from foreign countries. Factories equals Jobs, while sending money to US and Asia spells "evil capitalists".

8. You may expect city councils and municipal powers to take action. Contrary to state and federal governments, in the municipal scale, one enthusiast can make a project happen. City mayors are usually eager to find projects that can put their own city on the map, even if that means doing things nobody has ever done before.

Also, a thousand children and his families can represent five thousand voters, and that does make a difference in the next elections, specially if you promise to expand this one-school project to others when your term is ending. A couple thousand dollars is the just the scale they can afford: around the cost of a bridge, a new road or reforming a school.

7. You certainly can count on non-governmental organizations and non-profits. At this lower price point, it becomes affordable to seek alternative fundings. A NGO can amass such a small fortune with a few important donors, micro-loans, a online money raising or just from venture capitalists with a plan in mind.

6. Expect the eccentric riches. It may be ironic that the first confirmed buyer of the OLPC was Carlos Slim, the Mexican who became richest than Bill Gates, but it's not completely unexpected. Forward thinking billionaires like Slim, Jeff Bezos or Richard Branson or even companies like Google are known to spend huge amounts of money in projects that do not have a direct expectation to be lucrative.

It doesn't really matter if it's some grand plan, philanthropy or simply a way to leave a mark: that's how the new space race is being paid for. Lower the cost of a warm feeling in the heart and you can be certain that every unknown rich will be buying XO laptops for the neighborhood schools they grew up in.

5. Technology has a life cycle. A lot has changed in recent years but not this: breakthrough products still get in the market through the early adopters, and only then it will slowly take the mainstream.

The early adopters have the kind of personality that make them the perfect OLPC faithful: risk-takers, technology enthusiasts, eager to turn the education system upside down and get rid of old paradigms.

You know where you can find some early adopters? They are working as some liberal school director, as community leader or maybe even in charge of some risky but mildly funded government project. Guess where you can't find any: in the state department that is in charge of allotting billions of taxpayers dollars into a already tight education budget.

4. Let others make the trial and error for you. There isn't much criticism on the Children's Machine itself. But there is a lot in almost everything else. The contructivism, the UI, the curriculum, the "third world only" policy, even the concept of giving one laptop to every child has been scrutinized, and it's at least arrogant to suppose anyone really knows what's the ONE best solution for every community.

If the XO is a true open tool the process should be open also. Let the laptop be used in all countries, every kind of community, to be lent in libraries, given at random, sold by microfinance institutes, exchanged for good grades. The best practices will emerge, and the whole process will evolve.

3. The thousand-laptop number is big enough to create a critical mass in any community. In a school or community where are all one's friends are using a laptop then it's more probable that he will use the laptop as it was designed.

That is, he will learn Sugar from his peers, and will be able to use the native mesh network to play with the already installed softwares for playing music, writing collaboratively and share animations in Squeak. Give one XO to a single user in and in no time he will learn to wipe it clean, install an illegal copy of Windows 2000 and Office.

His experience of the whole OLPC program will be of a crappy processor running a pirated copy of an unsupported, insecure OS, with software that was designed less for students than for accountants. That's what we call second class online citizens.

2. Selling at a couple hundred thousands, the logistics are kept to minimal. No marketing is necessary as the kind of customer that buys such technology en masse is already aware of the OLPC program. Transport and shipping will be reduced to sending one container from Taiwan to somewhere in the world.

From that point the distribution to children, infrastructure and deployment rely in the hands of the clients – since they are the one with a plan. Support can be as simple as an laptop replacement - expect 5% of laptops to fail? Then build 1050 and wait.

1. Finally: the laptop technology is hot. But won't be hot forever. Remember how revolutionary was the iPhone when introduced? Today full screen phones are being announced every wee, zooming with two fingers became a cliché and even one tap scrolling - arguably the coolest feature - can be done on common softwares. It's a miracle that a product announced in early 2005 still gets media attention and woes it's users but how much longer can it keep pace?

Once flash-based laptops are commonplace, once the screen technology gets to the market and when mesh networking becomes more common, the XO will not stand out so much. And when other multipurpose computers and cell phones approach the sub $200 mark people will start opting for more conventional methods for their cheap laptop alternative.

It doesn't needs anyone to be better in all categories like low power consumption, mesh repeating while off or 1-second sleep state switch. You can even argue that the XO was not the designed to be top of the line.

But state decision makers don't usually understand that much about technology anyway, all you need to tell them is that it's cheaper, it's black and that it runs exactly like every computer he always used. And the green dream machine is gone.

Itsy Deal was built in 2007 as a service that would gather together all blogs that sold second hand clothing.

Human world migrations

Based on a buckminster fuller world map that has almost no distortion on land based distances, this is a map of the how, when and why humans colonized the world, based on mitochondrial evidence. Also plotted is where the ocean was ice during the last ice age, so you can see how the Great Britain was reached by foot. And note that as you can see from the temperature grid, humans migrated more when it was colder, seeking better lands.

The map of the oceans

Being a south american I’ve been always fascinated to views of our world that did not centered in europe (as the mercator) or put north as “up”. This one is centered on the antipode of Urumqui, most remote city from any sea in the world. This map was donated for the wikipedian community (where it was chosen ‘featured image’) and someone there described it as “When dolphins become ultra-intelligent, their world maps will probably look something like this.”

Running in the rain

_“In a near future, you will be able to write a doctorate only with images.”

Gui Bonsiepe

_

There is a mathematics book from the 19th century that proves all Euclidean theorems using shapes and colours as nouns. Running on the rain is an exercise on visual rhetoric.

The question itself is a popular saying that states that if you run under the rain you will get more wet than if you walk. This may be true, but you also get home faster. So the question is: is it worth running in the rain?

The insight was to represent all variables in this equation graphically. Speed, distance from home and even how much water you get per second are drawn as lines of constant sizes. This way time could be calculated geometrically. The total amount of water is finally calculated as an area, and by comparing those areas one can reach the final (and rather obvious) conclusion:

If you’re surprised by rain, run.

• about: Constantly made during many years..

A video about how technology may affect certain cultures, and what could be changed in the computer as it is today, so we will not need to change the cultures themselves. How to sell computers for monks is a proposition that designers should start thinking about the laggards, the last people to adopt technologies, as benchmarks. Because if we can fit their requirements of a non-intrusive and fail-proof equipment, then we will build a better machines for all of us.

If you like this you can see a first video draft (with a different script) here:

• about: Made in 2006/07 as a final diploma project

This link appeared here and there even got a minor digg, so a lot of people seemed interested into building thier own laser chess game

What are we talking about?

How the table was made?

It was a rather big game, a tabletop size. It had a wooden structure, covered in the outside with plastic (polyesthyrene if I remember well) sheets

How you make the laser visible?

If you don't make the laser visible you will be rather disappointed, having to search for where the red point had gone since you moved the mirror. You need particles in the air, and anything from clapping a chalkboard or smoking on the board will do. We decided to use dry ice, as we didn't have a smoke machine to spare, and the dry ice provides a quite simple set-up: just drop it on water. If you see closely there is a ditch around the table, it's where we filled with water and dry ice. Be careful: the dry ice doesn't give much smoke so make the ditch as small as possible to get the dry ice inside, but not too deep. Remember to make it impermeable, with plastic sheets and resin. We put a blue snake lamp for the effect. yes we could have used a smoke making machine, and we kept promising we would someday. But we never did, you know how those things go... Also: remember the thicker the smoke there will be a decay in the laser, as you can see one picture. It can be a part of the game rules, as you have to hit the goal, but you have to make the laser travel less than x meters or it will weaken too much

How you made the laser pointer?

That's amazingly more easy than it seems. We bought a couple of cheap laser pointers from the street vendor and opened it up to figure it out. I was a first year student, and my only experience in electronics was making cardboard lanterns with two A batteries. If you can build a lamp, you can build a laser pointer: open it up, put some cooper cables where the batteries used to be and link them to some AA batteries and add a on/off switch.

What about the pawns?

Those round pawns are made of semi transparent resin (so they look cooler when hit by the laser). We used a halved billiard ball as mold and asked a local glass shop to put the mirrors on it. Those yellow lines looks so cool!

Thank you buts that's more due to the lighting than from the lines themselves. We had a black wooden board painted in black, masked and sprayed up the lines. We used a neon colored yellow, nothing special. But put it under a ultraviolet lamp (those that you see in night clubs, I hope they aren't exactly the cancer emitting ultraviolet types) and the yellow neon will look infinitely cool. We also painted ourselves in invisible paint that shines on that lamp and put some techno music to impress our teacher

did it impress you teachers?

No. He was expecting us to make lego stack able bricks. The only thing stack able were the round pieces and they were merely complementary. But all our colleagues loved it.

What are the goals of the game?

They are two acrylic tubes, folded in heat in a L shape. We drilled two holes at the sides, and put it trough it, so when you hit the bottom the whole stick lightens up

Are there any game rules?

Well yes but I suppose you will want to make them yourself. Ours were not very imaginative: each turn you get to move and rotate one pawn, in order to try to reflect the laser to the opponents goal. If you move into an square occupied by an opponent, you capture it, which means the two pieces become one big non-reflective piece you control and can use to block the laser.

Laser Chess was designed and built in 2001, in participation with Ricardo Bacellar, Rodrigo Rego and Daniel Veloso. Those images are actual unaltered photographs of the working model.

|

www.wanderingabout.com

This website is a repository for design works and ideas by a brazilian student called Alexandre Van de Sande.

If you want to know more you can read about who is he or try to contact him.

• about: Made in 2006/07 for Kenwood corporation and École Nationale de Création Industrielle along with Clément Tissandier, using Adobe After Effects* for the movie and Max/MSP/jitter* to program the working prototype . *(both which I had learned the week before)

• about: Started making it in Rio in 2004 and finished in paris, 2005 using watercolor, ink, pencils and a projector.

probably anytime before we start writing down our christmas lists apple is going to release it's new ipod, an all bets on the net are that is going to have video support. There is not much inovation on that single piece, and in a market where windows media mobile failed to get off, where sony's PSP have a comfortable large screen for playing games and watching videos and most important cell phones are already able to stream any video to their screen apple is going to have to justify it's next step. But there is still another bigger challenge on portable video players: what are they for?

Videos, unlike music, requires your full attention and are unapropriate for jogging, walking, working and may be even ilegal while driving. An average everyday commute seldom lasts enough for your average 40minutes sitcom episdode. And if you do have a commute longer than that you probably won't want to show off that you are carrying a 400 dollars portable device, let alone rest it in your lap. Maybe you could want it during a trip, unless it's an air one as most airplanes have individual screens for low budget seats.This restricts drastically the usable window for a video iPod but apple seems to insist on it. They are smarter than me so, let's try to figure out why: My bet, think about portable, not mobile. A mac mini is a portable computer, but is far from being a mobile computer. It´s easy to carry it around, but you are not carrying it all the time. If ipod tries to be an all media in one, in your pocket, then I´m with microsoft in the opinion that thei´ll be won over by cell phones. But I trust apple´s inteligence on not going in that direction, but surprising us all. The new iPod could be:

1-Your personal mtv

That´s where apple want us to look. Just a natural extension of your music iPod, but instead of buying music you buy video clips at the ITMS, and let the thingy playing over your deck. But video could go way beyond that

2-Be your media center

Throw away your phillips DVD player. Have an iPod deck with video output. Leave you iPod there, and it´s all the media you need. An iPod as your home media center works as a concurrent of the huge and not so sucessfull windows media center PC. Or maybe the Xbox, which microsoft is selling as more than a video game but a whole media center (videos, music, games) for the teenager. And if you want to go to a friend´s movie party, why not take it all with you?

3-Be your remote control

It´s reasonable to believe the next iPod will come with bluetooth. It´s logical to think your iPod dock (or your macmini connecetd to your home theather) will also have. So why do not control all your movie functions from the wonderful-easy-to-use-patent-pending iPod interface. A quick look in the average home user and his one hudred buttons among his 10 remote controls in his living room reveals to anyone how much we need an upgrade in that system.

Maybe your next home theather may even come with bluetooth. Or your movie party friend´s.

4-Never rent a movie again

Never go to a blockbuster again. You could buy whole movies from your ITMS for a reasonable price and download directly from apple. The difference between buying or renting a movie are not so big in the end, you rarely get to see the same movie twice, downloading a movie from apple would be like a long term renting: you got the right to watch again the movie you picked up last week.

5-Be your TIVO

At the side of each podcast in the new iTunes you will se a column entitled "price". Althought until now are podcasts are free, the fact that this columns is there itches a lot of people. But althought everyone agrees that it would be foolish and absurd to try to charge for subscribing to a podcast when there are so many excelent ones free, most of us wouldn´t be offended if they charge you to subscribe to a sex and the city sitcom. What if the biggest TV series start being podcasted? Then apple´s iTunes may be the next big television...

Since Motorola and Apple announced a partnership the tech world started to speculate Apple releasing an iPod cell phone (which one can easily bet would be called iPhone iTalk or iAnything similar). Some initial images pop’d showing disappointing ordinary cell phones with built-in iTunes, without the iconic iPod click wheel. Later some pictured something a lot more applesque, but still a with a shy click wheel. The above is my contribution to apple: what better way to join wheel with a telephone than a beautiful dial-wheel phone?

The only things that are certain are less hype, but equally tasty. Apple licensed iTunes software for Motorola, long with it’s own digital rights manager, the Fair play. This does means a lot. Apple holds an almost monopoly in portable music players (read iPod). iPod only plays music bought from iTunes Music Store (or downloaded in the rule-less mp3). And, until now, the only player that could play music from the iTunes Music Store was the iPod. That means if you want to legally download some music and if you have (or wish) an iPod, you have to buy it from Apple. And today there no music player that can jeopardize iPod’s ubiquity, unless, the cell-phone. With this deal Apple is insuring it’s market dominance in digital music sale (and maybe in the near future, music recording), and Motorola can announce a cell phone that is friend with iPod users.

But what about an apple phone? As with the possibility of an Apple digital camera, only if Job’s designers can figure out something unique, advanced. Apple does not enter in a already saturated market to be one more. Never enter a war that you are not sure to win.

If you are a visual artist with a mac and an iSight camera, I recommend playing with quartz composer for a fun time. Below are the source files for the projects:

download quartz source files

Mind the pad is a mind-tracker application-concept for cell phones and PDAs that is at the same time a scribble & write sketch pad, an address book, agenda and file organizer.

The main principle behind the application is that information is not saved on a fixed location, but is stored as separate pieces that are auto organized as the user reach for it. Each piece of information, or meme, is a small text file along with a drawing (superimposed over the text), which can be linked to images or any file. Upon reading the user may underline some words and they will be transformed on special index words. When the user clicks an index word all information is re-organized and every data containing this index will be joined. Consequently, the user will be able to bridge ideas and concepts while searching for different data or files.

Each index is also associated to data fields as email or telephone number, so his address book is seaming less joined into the idea flow.

As the user does not need to previously organize it, information can also be inserted by medias such as voice and images. With a built-in text-to-speech technology, he may insert multiple, unrelated, voice memos during the day, which will automatically be converted into easily retrievable, therefore useful, data.

If the hardware has a camera, Mind the Pad becomes even more powerful. The user may add a voice comments to each photography he takes, that will be converted in an associated meme so he will be able to navigate thought his image library much in the same way his brain works when he is telling a story about a trip: by bridging and information association.

Later, the user can use the built in optical character recognition, to retrieve information about some images. Then he may quickly photograph an advertising, a note on the wall or a business card to insert the information about it.

• about: Mind the pad was designed in 2004 as a personal project

Free music might change our culture. But only if it creates a culture.

We live in a funny paradox. You can hear any music, from anywhere, given you already know it, or at least know how to spell it in a search engine. As a result, most of downloads are the famous artists seen in MTV, which makes the MTV guys very unhappy, as that´s precisely what they don´t want you to do. And at the same time, thousands of ignored musicians out there are actually asking to be heard, but remain in oblivion.

The result: recording companies prosecute people who can´t understand what they have done wrong (we´ve all always heard music for free after all), independent unknown artists who remain unknown artists, and radios plays old music as if nobody had done anything different in the last 10 years. It´s a everybody lose game.

That´s what radio Jaba it´s about.This is not a radio, nor a website, but it isn’t exactly a software neither. At least not yet: right now, it’s a conceptware, a proposal, spoken as an existing software, to stimulate discussion about the future of free music.

Radio Jaba is a mp3 player for exploring the musical world. You let him guide you, and he will give you information about the music you already own, bring you discussions and opinions about that musician, history on the albums, background for any musical genre, meanings, lyrics even translations for that song. You take the control and guide it, and it helps you make new unsuspected connections between musical genres, explore unknown realms of music, and get to know novelties uprising anywhere in the world.

how to put everything together

And, mainly, it analyzes your library to bring you new music, that you might want to hear, and mostly important that the artists want you to hear. This last piece of technology has been already explored in many softwares out there, like iRate, Gnomoradio and Indy.tv , to name a few. We´ve seen them, tested them, being inspired by them and hope for their future. They´ve done the technology right, but that´s not enough. It´s not about just downloading unknown mp3 to user´s HD´s, it´s about making a community. Bring information, bring people together, give them navigating tools and they will make you a community. It´s not just music, it´s about a whole free

Read more:

What it does?

And how will the musicians make money?

Criticism on similar programs

Related Technologies

Meta: about the project´s design

Download Now!

• about: Radio Jaba was a pet project of two students: interface designer Alexandre Van de Sande and Music Producer Pedro Borges. It was started in 2004 when we felt that alternative music needed a free distributing channel. About the same time many others were tinkering with the same problems and the emergence of Podcasting showed us that some things we only thought possible through massive computer algorithms, like filtering the gigantic amount of online music, was done thanks to the work of thousands of volunteers, who contributed with time and hosting space. A valuable lesson indeed. Pedro Borges is now a prominent podcaster in Brazil, and set up a site to help others spread the word. Alexandre, besides helping designing that site, still tinkers about media interfaces, as you may see in the rest of this site.

Can we map something as subjective as tastes? Alchemy of juices is a interactive infograph that is helps to choose a juice made with various fruits, by selecting either the fruits, the feeling or the taste. At the same time it tries to foresse those tastes and feelings of juices you mix there, based on user input from previous juices. Just as an alchemic diagram it’s about being a somewhat misterious but beautiful infograph.

Yes, we’ve got bananas, and thousands of other tropical fruits. And it is not amazing that in any casual restaurant in Rio de Janeiro you may ask to mix peanuts, banana, and amazonian fruits like Guaraná and Açaí. Best of all, they’ve got creative names: this one for example is called viagra. Watermelon and lemon is called “Sexy juice”. For some unknown reason we have to agree that there is something extremely sensual in that combination, even without tasting. Juices are more than just taste; they bring back memories.

The Alchemy of Juices is an experiment on information architecture which tries to reveal the most information possible in a visually simple and dynamic diagram. The main target is not to be easily readable at first, but to become intuitive once the logic is learnt.

The result is a rather mysterious-looking schema that allows the user to seek for juices based on a sensation or a fruit, to share experiences with other people, to guess what will be the result of a any mix, even to know what fruits you expect in this time of the year. All in one non polluted screen.

Once I head a teacher that, whenever asked how to know if a curve was correct would answer. ‘If it looks beautiful, it’s probably the correct one.’ Alchemy looks as an occult symbol: even though you don’t understand it, it’s attractive to look.

• about: Made with Flash and actionscript in the year 2003, along with Ricardo Bacellar, with the supervision of Gui Bonsiepe

It’s a virtual movie theather, where all friends watch the same movie at the same time. The avatar, controlled by a puppet-like remote, allows the users to hav movements without sounds to allow silent comunications. Also, it can act as a passive microfone transforming the audio in semi controlled movements from the avatar.

Also see this Bill gate’s comment on the project

• about: Made for the Microsoft Research Design Expo 2003 contest, along with Rodrigo Rego and Ricardo Bacellar

Enter the maze

Game design and programming. While figuring out an algorithm for building a maze with only one right path, it became clear that in such a maze the walls would be a labyrinth of it’s own. Then it was a natural evolution transforming it into a maze whith special stairs and bridges so you could walk over walls or on the ground.

For centuries labyrinths have been used for meditation. Taking the longest route to go through a short distance, priests would use that time to pray and think. Back then, no one had invented traffic jam.

I also used my long hours in traffic jams to read and think. So I found some funny things about them. The first is that in a true maze (a labyrinth with multiple ways) every point is reached through one and only one way. Another, is that to build one like that all you need is to start with a open circle and draw lines starting from another line and ending anywhere as long as it does not cross or touch any other. And finally I’ve realized that in a maze built like that, not only the space between, but the walls also form a true maze. Beyond programming the algorithm, I drew the character animation.

• about: Made in 2002. Animation, programming, and algorithm in Adobe Flash and Actionscript.

The rule of thumb in the first year of college is: bend the rules to see how far they can go. The teacher asked the students to build a game with resin pieces, just so we would know how to mould in resin. We added dry ice, acr ylic tubes and a laser beam. Laser Chess is a strategy game for two player s. Each one has four semi-spheric pawns (molded after a hlf cutte billir ball) with a mirror face, and the game objective is to reflect the central laser beam until it hits the opponent’s goal, an acrylic tube which glows red when illuminated. The game was constructed on a 1.2 m (4 ft.) high table with a space under which there is a blue light and a solidified carbon dioxide vapour. For the laser beam we had to unbuild many laser pointers until we figured out how to make it work with ordinary batteries. The final presentation was held in a dark room, with techno music and purple lights.

How the table was made?

It was a rather big game, a tabletop size. It had a wooden structure, covered in the outside with plastic (polyesthyrene if I remember well) sheets

How you make the laser visible?

If you don’t make the laser visible you will be rather disappointed, having to search for where the red point had gone since you moved the mirror. You need particles in the air, and anything from clapping a chalkboard or smoking on the board will do. We decided to use dry ice, as we didn’t have a smoke machine to spare, and the dry ice provides a quite simple set-up: just drop it on water. If you see closely there is a ditch around the table, it’s where we filled with water and dry ice. Be careful: the dry ice doesn’t give much smoke so make the ditch as small as possible to get the dry ice inside, but not too deep. Remember to make it impermeable, with plastic sheets and resin. We put a blue snake lamp for the effect. yes we could have used a smoke making machine, and we kept promising we would someday. But we never did, you know how those things go… Also: remember the thicker the smoke there will be a decay in the laser, as you can see one picture. It can be a part of the game rules, as you have to hit the goal, but you have to make the laser travel less than x meters or it will weaken too much

How you made the laser pointer?

That’s amazingly more easy than it seems. We bought a couple of cheap laser pointers from the street vendor and opened it up to figure it out. I was a first year student, and my only experience in electronics was making cardboard lanterns with two A batteries. If you can build a lamp, you can build a laser pointer: open it up, put some cooper cables where the batteries used to be and link them to some AA batteries and add a on/off switch.

What about the pawns?

Those round pawns are made of semi transparent resin (so they look cooler when hit by the laser). We used a halved billiard ball as mold and asked a local glass shop to put the mirrors on it.

Those yellow lines looks so cool!

Thank you buts that’s more due to the lighting than from the lines themselves. We had a black wooden board painted in black, masked and sprayed up the lines. We used a neon colored yellow, nothing special. But put it under a ultraviolet lamp (those that you see in night clubs, I hope they aren’t exactly the cancer emitting ultraviolet types) and the yellow neon will look infinitely cool. We also painted ourselves in invisible paint that shines on that lamp and put some techno music to impress our teacher

did it impress your teachers?

No. He was expecting us to make lego stack able bricks. The only thing stack able were the round pieces and they were merely complementary. But all our colleagues loved it.

What are the goals of the game?

They are two acrylic tubes, folded in heat in a L shape. We drilled two holes at the sides, and put it trough it, so when you hit the bottom the whole stick lightens up

Were there any game rules?

Well yes but I suppose you will want to make them yourself. Ours were not very imaginative: each turn you get to move and rotate one pawn, in order to try to reflect the laser to the opponents goal. If you move into an square occupied by an opponent, you capture it, which means the two pieces become one big non-reflective piece you control and can use to block the laser.

• about: Made in 2001, along with Ricardo Bacellar, Rodrigo Rego and Daniel Veloso