danabramov

I don’t understand where this misunderstanding about my article comes from. I am saying that the sound at the intersection of “s” column and “i” row is “shi”. My article uses romaji so this is self-consistent. I am also mentioning that there is an alternative system that would romanize it as “si” but that’s not the one I’m using in my article.

> there is no "si" in the hiragana table, so s_ + (i) = shi. […] this is why it's important that you don't actually "think in" romaji. […] i'm using romaji as a convenient way to refer to phonetics in text. however, your "mental algebra" should match the hiragana table.

> this is why it's important that you don't actually "think in" romaji. i'm using romaji as a convenient way to refer to phonetics in text. however, your "mental algebra" should match the hiragana table.

Then the article includes an exercise that verifies the reader’s understanding.

I also included a note:

> (note i could also have used a different romanization that renders し as "si", つ as "tu", and ち as "ti" for this article. i decided to not because everyone else uses romaji, and once you understand this point once, you shouldn't have a difficulty doing this in your head.)

Where is the factual mistake here? “si” is invalid romaji, my article uses romaji, therefore it’s invalid.

All of this is described just below, in the section called “why romaji is actually bad”, with these specific examples being tested.

> It also breaks for godan words that end in "u" which become "wa" in the negative form.

This is also described further below in the post.

> as you frantically try to back-translate everything into romaji, but also removing excess w's and converting nda's as you go

I see “understanding the system” and “applying it fluently” as two separate activities. I find romaji more illustrative for the former because the system is phonetical on a sub-mora level. Whereas kana is more helpful for the latter. I don’t assume my reader is an idiot, and so I assume that they would be able to pick the right tool for the job on their learning journey. The fluency always layers on separately anyway, understanding doesn’t “help” there. It’s just that personally I find understanding a great motivator (and fallback) for developing fluency.

I think you’re taking a lot of stuff for granted. “Just” do cards etc. You’re using the word “stem” but what’s a stem? Why do we sometimes inject -i or -a (or -wa) there and sometimes we don’t? You still have to learn that and understand that. That’s what I’m describing in the article. If you already know stems and how they compose with suffixes, congratulations, you won’t find my article useful.

I prefer having a system to simply memorizing. I don’t know what you mean by “so much effort”. I am literally just describing the system as it is brick by brick. If you see an opportunity to simplify, you’re welcome to provide a specific suggestion. I find this system rather elegant, and I tried to build it piece by piece because that’s my preferred way both to learn and to teach.

>the whole page barely mentions the interesting ones 80% of the way down

The te/ta-form is genuinely a separate system linguistically with its own heritage. So it makes sense to look at it separately. I don’t consider it more “interesting” and I’d argue getting the details right with other forms is much more useful coverage-wise. So I didn’t spend much time on te/ta-form. (That said, even for -te/ta form, I find it calming to think of -nda as a contraction of -nita, and so on, which AFAIK is in the ballpark of what historically happened.)

> Language learning and exercise are the two things where I've found the programmer's instinct to "work smarter, not harder" works against you

I agree you need to put time to practice and all that. But if there’s a genuinely simple system underneath, I always prefer to see it. Even if there’s a layer of memorization and repetition to achieve actual fluency. Japanese conjugation is a rare case where the system actually is very clear and methodical. The article is written for people like me who also prefer to know it. There’s literally thousands of resources that teach it your preferred way, so I don’t understand the impulse to complain about someone teaching it differently for a change.

You can’t “get” the majority of the people to see anything, that’s not how anything works. Neither on centralized systems, nor on Mastodon, nor in real life.

On a centralized platform, if you get banned, there are no steps you can take. Your account is down — goodbye.

On a Mastodon instance, there are also no steps you can take. Your account is banned on the instance — your entire identity goes down with it.

On atproto, it depend on whether you’re banned at hosting or app level.

If you get banned at hosting level (usually something clearly illegal would trigger this), you’d have to find another hosting (assuming apps haven’t banned you too).

If you get banned at an app level, people will see you through different apps. You’re right that this presupposes that there are apps that (1) people use, that (2) haven’t banned you, (3) and that display the same type of content.

But, even if you’re looking from solely censorship resistance perspective, atproto at least enables competition in moderation space to happen. If enough people disagree with the lens, it is possible to build a an alternative lens over the network.

This isn’t theoretical — there was a situation like this where a person got banned at Bluesky app, but the Blacksky community wanted to reverse the decision. When Blacksky got an independent app database running, they overrode it. But yes, this does require investment and a subset of community being interested in alternative moderation / features / etc. You can’t “force” people to hear you but there’s a market for alternatives.

> How do I build a relay that fetched all content from people I follow, plus all replies to those posts (no matter who sent them), plus automated backfilling if I click on the profile of someone who I'm not following yet?

The realtime part is trivial. You just filter the stream of everything as it comes in.

Backfill would either require you to index the network yourself or to rely on existing indexes. You could use Constellation (https://constellation.microcosm.blue/) to fill up threads (query by thread root ID), and you’d hit the user’s PDS to fill up their profile page.

You could actually see that in practice now at https://reddwarf.whey.party/ which my article links to. It’s a Bluesky client that doesn’t have a server at all (and doesn’t hit Bluesky API). It’s lazily getting stuff on the client purely from PDS’s and from Constellation. It’s a bit slower than an appview-backed experience but it works fine.

It’s just as cheap as hosting any webapp.

But what you’re asking is not that. You seem to be saying “I want to host my own Bluesky appview”. That’s resource-intensive for the same reason “I want to host my own Twitter backend” is expensive. It has nothing to do with the protocol! If you want to host a database application server that stores gigabytes of data from millions of users forever, you’re gonna have to pay for that. This isn’t some kind of gotcha with the protocol, it’s just common sense.

That’s the “instance brain” from my article. You’re used to the shape where the only thing you can host is a “isolated copy of the same app that only deals with a few users”. But that’s not the atproto topology! What atproto lets you host is the real thing. Like a second real Twitter app that “just works” with all existing users. That’s the value proposition here. Or — if you’re not actually in the mood to host a product with millions of users — you can make your own app that has nothing to do with Bluesky. And of course your own app aggregating its own data would be cheap to host because it won’t be aggregating millions of records.

Do you see the disconnect? Atproto allows competition at big scale — actually forking real products — which AP doesn’t do in principle. But you’re using this ability as a knock again atproto. Atproto scales arbitrarily up, so you take the highest scaled up example you can think of (Bluesky app with all its users and posts) and compare it to the cost of running the most scaled down version of AP (an isolated app for some people).

To make the comparison fair, we’d need to scale atproto down in your example. You can definitely achieve scale identical to Mastodon (and thus identical in costs) by taking the Bluesky app server and adding custom logic which ignores all events that aren’t relevant to some hardcoded lists of users (your “member list”) or people they follow. That would be an accurate comparison, and yes, you could totally host that.

People don’t do that because it’s kinda niche. Maybe it would be nice if there were ready-to-go distributions of Bluesky appview that do this kind of filtering. But also — it’s just kind of a non-goal for most developers on the platform. Most developers create their own different apps, rather than host alternate projections of the Bluesky content of the whole world.

The difference is that it’s competitive. New apps can rise up that provide alternative lenses over the network. In the crudest case, literally showing everything. Which is what you wanted. Maybe that won’t get into an App Store but it definitely works if there’s demand for that.

>I say “Mastodon” here because if I say “ActivityPub” instead, a crowd of people will show up and say that actually what I’m describing is how Mastodon chose to implement ActivityPub. Whereas ActivityPub by itself does not really specify how to actually use it in practice.

I understand there's other ways to use AP, but when people say "where are Bluesky instances" they are specifically comparing AT to Mastodon's AP topology.

As I mentioned in the article, I literally migrated to https://eurosky.tech/accounts/ yesterday.

Yes, a lot has happened! The scene still has very much indie vibe, but there's a lot going on in the Atmosphere. Atproto blog has recently started showcasing some community projects so check it out: https://atproto.com/blog

>That still leaves governance of the protocol as a problem. That would ideally need to be untangled from Bluesky as well. But that seems doable as well.

The core part of the protocol is literally going through the IETF process now: https://atproto.com/blog/taking-at-to-the-ietf. It's happening.

Re: other things, it's up to the community to do this. You can get involved. BridgyFed is doing cross-protocol federation and has been doing for a while: https://fed.brid.gy/. I'm sure there are other things that could be done in that space.

I still don't quite understand your comment.

>If there are advantages to ATProto over ActivityPub in this kind of deployment setting, they don't seem clear enough to offset the weird corporate parentage

The advantage of atproto is that it's literally "the web". Every app can aggregate from entire network, there's no isolation by default. It reduces to the degenerate smallest case just the same — you can have a single-user app that simply displays content from your PDS. But you can also start aggregating things (e.g. comments left by other users, which are stored on their PDS's). The whole big idea of atproto is that every app is effectively a CMS for app-agnostic "model" web.

What is the concrete thing bothering you? AT is already in the IETF process. It's not some weird corporate thing.

Bluesky is two things. There’s “Bluesky hosting”, and there’s “Bluesky app”. Conceptually and on the network level they have nothing to do with each other. These are different pieces of software running on different stacks and they are agnostic of each other. Bluesky the company happens to run both because it’s kickstarting this whole thing. But you can swap hosting (I just did) while using Bluesky app, or you can keep Bluesky hosting but use other apps in addition (like Tangled) or instead of Bluesky (like Blacksky).

Eurosky is a hosting provider primarily. They happen to also develop an app (Mu Social) but afaik currently that’s just a skin for the Bluesky app (it talks to Bluesky app API). Nothing stops them from removing that dependency (like Blacksky did) though and making it an independent forked app though.

So the answer is — companies and organisations in Atmosphere often provide services for different roles in the system. Some do just hosting, some do apps, some do other kinds of network infrastructure that is used by many apps, and many do multiple things at once.

Concrete example: Bluesky banned a person, and Blacksky community disagreed with that ban. When Blacksky switched http://blacksky.community app to have its own complete stack (including its own database), that person’s posts became visible there (despite them being banned on Bluesky app) because they reversed that moderation decision. This was possible because the data for this person’s posts still lives on their PDS.

In general, the data being “pulled outside” products is what enables new products (or forks of products) to come onto the scene and immediately begin competing because they don’t have to solve the “cold start” problem. If you log in, all your stuff is “already there”. And it’s the same shared world so the community doesn’t get forked. You’re just looking at the same underlying data under a different lens, and products act like lenses rather than boxes.

This doesn’t mean that “censorship” can’t exist (every layer can ban you, as always) — but it means that every layer of the stack has opportunity for competition that isn’t possible with centralized platforms. In fact, arguably, it’s more flexible than a Mastodon instance because you can’t fork a Mastodon instance “with all its users” and offer a version that reverses some moderation decision. In atproto, you can.

When developers feel empowered to revive products or fork them, I think that eventually seeps into communities. That it’s another way of doing things. It doesn’t happen overnight but this energy exists in the Atmosphere. Maybe loss of Bluesky is not survivable culturally at the moment, but maybe it will be in a few years as Atmosphere grows and matures.

So the new thing here is that if everyone’s data exists in this format, the competition between apps is guaranteed. Because a competitor doesn’t start with nothing: they start with the same userbase and the same content. They can immediately start competing on features, moderation, product experience, etc, without first “luring” everyone to register again and start their entire graphs from scratch.

I think that makes a big difference. Don’t you think?

Also the best algorithmic “For You” feed on the app runs off someone’s gaming computer at home

AT doesn’t have this kind of issue even without Relays. This is because PDS never talks to another PDS so there’s no quadratic growth of edges. PDS only talks to apps, and there’s limited amount of apps on the network. And end users hit apps which cache stuff, so apps tend to take the user traffic hit.

Relays are helpful more on the app side because you don’t want to teach each app to crawl PDS’s and subscribe to them.

I didn’t dive into Relays in the article because they’re kind of a “next obvious optimization” but not really inherent to the model. There are other models like apps hitting shared backlink caches (like Constellation). Relay isn’t fundamental in the way hosting and apps are.

Okay, but that's always the case when you get banned from a service. The difference here is that it's possible to build a competing service with different moderation decisions being a lens over the same data.

If you want to filter for events based on some heuristic (e.g. only from follows of server list), you can do that. You can then specialize that further. E.g. for ongoing threads that already pass your filter, you could add their IDs to an array, and accept all replies for those threads as well into your DB.

You already get a stream of everything so you can scale down what you write to DB to exactly the characteristics you need. Including keeping threads cohesive.