Yesterday, I checked in some code so that my Fediverse server can respond to requests to the api/v2/instance endpoint so that code of conduct rules can be fetched.

Although the code is already running, I plan to add more on this feature so that the server can better communicate the code of conduct to its peers. This is related to what Robert W. Gehl calls the “covenantal fediverse” in his book Move Slowly and Build Bridges. I still have the last third of the book left to read but I have noticed that Gehl does not mention Bluesky until the epilogue. People on the Fediverse can communicate with people on Bluesky through Bridgy Fed and about a year ago, I added Bluesky support through Bridgy Fed to my Fediverse server.

Although it seems Bluesky does not have API support for requests to fetch code of conduct rules, it does have Community guidelines and it seems there could be consequences including account termination when an account does not follow the guidelines. This weekend, people on the Fediverse have been sharing instructions to block Bluesky since Bluesky gave a blue check to ICE. Considering the history of behavior by X accounts related to ICE, this is a completely reasonable response. It will be interesting to see if this new Bluesky account can last a week without breaking Bluesky’s community guidelines. If they do misbehave and Bluesky does not aggressively respond to the infraction, Bluesky will be blocked on my server.

I was glad to hear this week that Texas A&M and Houston will finally be playing each other on September 12 at Sugarland Ice Center. I attended UofH’s first game in 80 years 2 years ago and they’ve done a great job building up the team since then and I expect them to be competitive for the first game of the season.

Activitypub addresses the problem of participating in a decentralized social network with a low barrier to entry. You participate through the server you have joined but often times the people you want to interact with reside on other servers. For instance, if you want to follow a friend, visiting that friend’s url does not provide a simple follow button. That simple follow button is on your own server but you need to navigate to your server’s profile page for your friend who is on a remote server. An easy way to do this is to perform a search on your friend’s webfinger address which looks like an email address. Your server can make a forward discovery request to ask for the url of your friend’s actor document so that you can visit your server’s profile page for your friend.

Your server needs to do more than forward discovery to validate that the actor url actually belongs to the requested webfinger address in case the domain of the webfinger address is different than the domain of the actor url. In this case, after fetching the actor url, your server needs to construct a 2nd webfinger address composed of the preferredUsername it found in the actor document followed by the domain of the actor url. Your server can make a webfinger request to this 2nd address and use the response to verify that the subject matches the original webfinger address that you submitted in your search. If they don’t match, your server can display the profile associated with the 2nd address and ignore the original webfinger address since the validation failed.

I wrote a should use the custom domain example spec to make sure the server can accommodate a custom domain different than the domain in the actor url.

In the example spec, we are given bob@example.com whose webfinger points to an actor document at activitypub.test:

let(:bob_webfinger_info) { {"subject" => "acct:bob@example.com", "links"=>[{"rel"=>"self", "type"=>"application/activity+json", "href"=>"https://activitypub.test/users/bob" }]} }

It is not enough to fetch the actor document and assume bob is at activitypub.test. Instead, as Mastodon does, a reverse discovery should be performed by constructing a new WebFinger address by combining the preferredUsername from the actor document and the hostname of the id of the actor document.

In the example spec, this new WebFinger address would be bob@activitypub.test and, in this case, the test host activitypub.test returns a webfinger response that confirms that the subject is bob@example.com that was requested with forward discovery.

Another example spec should not use the custom domain if subject returned by activitypub server is different than the original subject tests when george@example.com is not recognized by the host activitypub.test who george points his webfinger address to:

let(:george_webfinger_info) { {"subject" => "acct:george@example.com", "links"=>[{"rel"=>"self", "type"=>"application/activity+json", "href"=>"https://activitypub.test/users/george" }]} }

In this case, the validation fails because the host returns acct:george@activitypub.test in the 2nd webfinger request instead of acct:george@example.com so example.com is discarded and the domain of the account should fall back to activitypub.test.

Bitcoin failed. J.P. Koning notes in The end of El Salvador’s bitcoin payments experiment:

But here was a government that was going to champion the stuff, nullifying all of the headwinds against bitcoin in one stroke! The government meddling hypothesis would be put to test.

The Salvadoran government used a combination of sticks and carrots to kick-start adoption. First, let's list the carrots. The capital gains tax on bitcoin was set to zero to remove the hassle of buying stuff with bitcoin. The government also built a bitcoin payments app, Chivo, for all El Salvadoreans to use. (Chivo also supports U.S. dollar payments.) Anyone who downloaded Chivo and transacted with bitcoin would receive a $30 bitcoin bonus—that's a lot of money in El Salvador. Gas stations offered $0.20 off of a gallon of gas for customers who paid with the app. People could also use Chivo to pay their taxes with bitcoin.

The biggest carrot was zero-transaction fees. Any payment conducted with Chivo was free, as was converting bitcoins held in the Chivo app into U.S. dollars and withdrawing cash at Chivo ATMs. These Chivo ATMs were rolled out across El Salvador and in the U.S., too, to encourage the nascent U.S.-to-El Salvador bitcoin remittance route. Bitcoin ATMs are usually incredibly pricey to use, but in El Salvador the government would eat all the transaction fees. What a fantastic deal.

As for the stick, Bukele introduced a forced-tender rule. Beginning in 2021, businesses were required to accept the orange coin or be punished. This was costly for them to comply with. They would have to update point of sale software, signage, train employees, and set up new processes for handling bitcoins post-sale.

By all rights, this combination of sticks and carrots should have led to a flourishing of bitcoin payments. But it didn't.

Koning concludes:

The saddest thing about El Salvador's bitcoin experiment is that all sorts of time and resources have been wasted. El Salvador is not a rich country. The money spent on building and operating Chivo, compliance by businesses, bitcoin signage, and subsidies could have been better deployed on more important things like health and education.  One hopes that other countries learn from this experience and avoid going down the same route that El Salvador did.

Deadly D.C. Plane Crash Comes Months After Congress Ignored Warning About Traffic at Reagan Airport

As the new administration is playing stupid games, yesterday morning, prior to yesterday’s aviation disaster, professor Thomas Schaller cautioned:

An FAA employee I know confirms agency already lacks sufficient air traffic controllers. The so-called “buyouts” and other attacks on federal employees won’t help. Remember that fact when the flight delays (crashes?) commence and Trumpers start falsely blaming DEI or Biden.

This should be a wakeup call and I have a deeper appreciation for people like Phyllis Fong who this week have resisted the illegal orders that are already causing significant harm. On the other hand, if you like anarchy and disaster, congratulations.