dump since:2023-01-06 from self-replies

content/_dump/activitypub-2.md

@@ -0,0 +1,35 @@
+https://mastodon.social/@trwnh/109979200684979970
+
+@ people who keep saying we should rewrite the activitypub spec to ensure better interoperability with existing fedi projects
+
+[](specs-are-enough.jpg)
+
+idk how else to say that if you want to be compatible with a project then you need to have a shared worldview and conceptual space, and this necessarily involves communicating with that project on some level (by reading their documentation, asking their devs questions, etc) in order to know what their expectations and requirements are
+
+the question of "interoperability" makes no sense on its own. you must always ask, interoperability with what? and on which conditions?
+
+like, we all use activitypub more or less according to the spec, and that's because the spec is simple, it's basically just "HTTP POST to inbox". we could theoretically construct any as2 payload we wanted, but we largely limit ourselves to Create Note... why? because you want to be compatible with mastodon, right? and that's the real issue.
+
+there are things that mastodon et al do that are within some spec -- webfinger for translating usernames to actors, for example. then there are things that are technically a spec but outdated, like http signatures (cavage draft) and ld signatures (obsoleted entirely). and then there are things that are not specced -- quirks of the implementation that must be respected, things like using Note, how to structure a Mention, the use of specific algorithms for signatures. maybe these can be negotiated
+
+crucially, sometimes the assumptions you make, the quirks your software has, these will not line up with the assumptions that others make, the quirks that their software has. you might even disagree entirely, and without the possibility of reconciling those opposing assumptions.
+
+consider the assumption that every actor has a username, and that this username identifies them more canonically than their own activitypub identifier. what if you disagree? well, that's an incompatibility.
+
+how do you handle the root of identity being the activitypub id, versus the root of identity being the username, versus the root of identity being some cryptographic key? what is one to do, if one wants to be "compatible" and "interoperate" with three different softwares each following a different one of the above assumptions about identity? are these softwares even meaningfully part of the same network? and which of these three networks is the "true" "fediverse"?
+
+and even within those identity schemes, we might still have to consider further parameters, like the expectation of only supporting HTTPS URIs. or, let's imagine that we choose to use or support DIDs -- now, which DID methods do we support?
+
+all of these are decisions that each project has to either make for itself, or vest authority in some other entity to make those decisions in a binding way -- by publishing some meta-spec, some conformance profile, basically a bundle of specs that should be followed and their particulars.
+
+and even *then*, you will find some quirks remain, some projects are coded in a way which has implicit expectations. the more you try to eliminate these, the narrower the scope or conceptual space becomes.
+
+with enough limitations, you end up with what is basically the same software, just with different implementations. if mastodon, pleroma, and misskey all were overspecced like this, you may as well view them as "fedi implemented in rails", "fedi implemented in elixir", and "fedi implemented in nodejs".
+
+so, in closing, i leave with this to consider:
+
+is your view of the "fediverse" limited only to the conceptual space of existing projects? and, if so, then which ones?
+
+or will you allow yourself to dream a little bigger?
+
+https://www.youtube.com/watch?v=WcGbnX8Ay38

content/_dump/activitypub-proglang.md

@@ -0,0 +1,20 @@
+people think activitypub is a network protocol when it's really more like a programming language. you don't say "compatible with c++" you say "written in/with c++". similarly, we might say that fedi is "written with activitypub" or "implemented using activitypub", not "compatible with activitypub" or anything suggesting a network.
+
+analogously:
+
+ap = inter-process communication (e.g. d-bus)
+as2 = data interchange format (e.g. protobuf)
+json-ld = media type
+rdf = facts and logic
+
+if we're being honest the majority of "fedi" is part of the "network" that is "compatible with mastodon". mastodon *is* the network protocol. we just express it in terms of "mastodon-flavoured activitypub"
+
+put another way, there is no such thing as "fedi", but rather, multiple different and distinct "fedis" that only partially overlap.
+
+it occurs to me that activitypub may be best thought of as a cms with an optional distributed storage backend
+
+similarly: no one in fedi is doing real activitypub. it is probably more appropriate to say we are doing AS2 + Linked Data Notifications
+
+side effects are more accurately defined by the mastodon documentation than by the activitypub spec
+
+we're kind of in the situation where someone has invented the C Programming Language, maybe D-Bus, but we still don't have a FreeDesktop.org or XDG equivalent.

content/_dump/defining-quotes.md

@@ -0,0 +1,58 @@
++++
+date = 2023-05-02
++++
+
+fwiw my take about quotes is that either
+
+- they're just links with special tag markup that lets them be identifiable as activitypub objects
+- they're supported more at the protocol level a la Announce with content, or possibly a "quotes" collection a la "likes" and "shares"
+- they represent a new context (assuming mastodon ever adopts a first-class concept of conversations or threads, instead of relying solely on inReplyTo chains for logical grouping)
+
+my further idea was to decide if it notifies based on whether the type is Link or Mention (a la webmentions)
+
+in an alternate timeline we could have had generic rendering of activities based on name/summary/content and maybe actor/type/object
+
+such a generic renderer would be something like...
+
+> <darius> <Announce> <some-post>
+> <Announce.summary>
+> <Announce.content>
+
+filling in the last two lines for summary and content
+
+> Darius boosted a post: "The problem with this is..."
+> "I disagree with this analysis."
+
+also this just highlights what i think a "quote post" should really be: more like a "loud reply". in a more ideal world it would use `inReplyTo` + a new `context`.
+
+yes, a regular "reply" is in effect a "quote" the second you embed the post you are replying to. look at the IndieWeb for example. what is the functional difference?
+
+the problem of course is that mastodon doesnt show replies in timelines, and doesn't have a proper concept of contexts aside from reply-chains. but at least half of that is a matter of policy, so it could be changed.
+
+imagine a property `toot:quoteReply` that is a boolean. if true, it embeds the `inReplyTo`post above your post. it also sends such posts to follower timelines.
+
+fundamentally there's the intent and the interpretation, intent can be seen as how you author the activity, interpretation is the processing rules applied by the receiver. if this were a proper spec, the two would be the same and there'd be no ambiguity, but... well, y'know.
+
+there's also the rest of the ecosystem of course, there's the "tag a substring of your content" as Foundkey does, in the past there was even "attach the post you're quoting" which Hubzilla and/or Zap did, there was also the proposal to "add content on Announce" which gargron and lain favored but never implemented. and then there's the two new ones -- "just make it a special type of reply" as i propose, and "just make it a new Activity" as you expressed just now
+
+we should focus on generic data modeling, describing resources and how they are related. mastodon doesn't do a good job of that, sure... and that's how we end up with leaky abstractions. it's a good idea to leave as much of the app-specific stuff out of the data model as we can. otherwise we just end up with The Mastodon Protocol which is built to interop with the mastodon app specifically
+
+like we have tag, attachment, inReplyTo, Announce...
+
+- tag = describing entities within the natural language properties (often microsyntaxes)
+
+- attachment = sidecar entities (not necessarily media)
+
+- inReplyTo = referencing a prior object (or objects) for which your current object can be considered a response
+
+- Announce = add to `shares` collection if present (this is the weakest one, to be fair)
+
+> I do agree with you that quotes are basically a form of loud reply
+
+semantics aside, i think functionally the difference is really the fallback
+
+- an Announce with content is basically "reshare with additional content" semantically, but it falls back to being a regular boost, and to control quotes you'd need to similarly be able to control boosts
+
+- a Note with inReplyTo + quoteReply=true would fall back to a regular reply. this means that when reply controls get added, you get quote control "for free"
+
+the other functional difference between those two is whether the "quote" gets added to `shares` or to `replies`

content/_dump/domain-number-system.md

@@ -0,0 +1,40 @@
+https://mastodon.social/@trwnh/109965906891374818
+
+we have a domain name system but why don't we have a domain number system
+
+just like we can register human-friendly names, we should be able to register persistent machine-friendly numbers to websites and domains. the name and number are aliased together, or we map name => number => ip address
+
+yes this idea is copied from xri i-names and i-numbers, it's one of the best ideas to come out of that effort (aside from delegation of authority at any point in the identifier)
+
+the world if xri took off
+
+future.jpg
+
+i've talked/thought about doing something similar with webfinger, but the "authority delegation" bit is really hard without a persistent unchanging identifier in some common authoritative namespace. you can defer to some other DNS domain's webfinger endpoint, but that doesn't get rid of the fragility in expiring or reassigning domain names.
+
+it's interesting that bluesky comes to a similar conclusion with its "placeholder" DID scheme, did:plc: -- identifiers are centralized around a single "PLC server". the DNS stuff maps to a did:plc: that gets resolved by the centralized resolution server.
+
+we could do something similar with a centralized server/domain that did nothing but assign identifiers and map to current location... of course, that doesn't solve the problem, it just shifts the burden.
+
+so here's a crackpot idea that requires "minimal" changes to the way the world works
+
+1. register a TLD with the IANA/ICANN -- let's call it something like .uuid
+2. allow anyone to register UUIDs on this TLD -- this should be as easy as registering any other domain name, but instead of getting to pick the name, it's auto-assigned to you
+3. CNAME your desired public-facing domain name to the .uuid domain you registered
+4. optionally: run some software to "reverse map" your .uuid URIs (Webfinger)
+
+you could also use plain old HTTP redirects instead of Webfinger, if you trusted the thing at the other end to stay online
+
+but the main thing would be being able to use
+
+trwnh.com/some-resource => 05517367-0a6a-42c1-9810-9fcf264a505b.uuid/some-resource
+
+and then later change trwnh.com to some other domain
+
+any software/application dealing with identifiers SHOULD support using the "canonical" identifier, so you can signal that the .uuid-assigned URI is the canonical one
+
+crucially, the .uuid registry would never expire, and probably it should be free. the goal is to never let the .uuid registration lapse, ever
+
+maybe your domain name registrar could even host a reverse-mapping server for you, if they wanted to expand their services?
+
+also something to consider: under what circumstances might an entire TLD lapse? like this is super unlikely, sure, but what happens if the entity behind some TLD in the IANA root zone database goes insolvent?

content/_dump/drowning-in-awareness.md

@@ -0,0 +1,9 @@
++++
+date = "2023-01-20"
++++
+
+i am reminded of an essay i read once called "avoid news" which might sound extreme to some people but it actually has a simple premise: most of what you encounter in media suffers from context collapse and/or is not actionable. therefore it can never truly be relevant. what is far more valuable is filtering through the news for anything actionable worth educating people about, and presenting it in a more relevant and digestible way. not everyone should have to do this.
+
+i'd really go further and say that these days, if you don't have a material call to action, you have nothing. what do you expect to accomplish by sharing what you're sharing? "awareness" on its own is not enough; it can even be an actively bad thing if you end up paralyzed by inaction and despairing over it. far better to actively educate people that need educating, instead of simply "raising awareness".
+
+like, ok, i'm aware. now what?

content/_dump/fedi-critiques/blocklists-as-hoa.md

@@ -0,0 +1,27 @@
+it's a bit weird that some fedi blocklists use language like "fence" because whenever i see that, i don't think "safety", i think "homeowners association", and i think the HOA characterization of certain blocklist efforts is actually not wrong. it is reminiscent of the abstract desire for "safety" rather than any sort of concrete safety or just treatment. "freedom of association" only goes so far to justify punitive and destructive actions at an instance-state level
+
+of course, what is to be done? what is a more appropriate solution? i think whenever such blocklists are circulated, it usually represents a failure mode at an institutional level. the rise of blocktogether on twitter was due to the systemic failure of their moderation. earlier fedi users may or may not remember the infamous "wil wheaton blocklist" that imported from infamous terf randi harper, who billed her list as "99% gaters and mras" (and i guess 1% trans ppl?)
+
+so i think the "question of the day" now, is, what is the failure of fedi and how could we have avoided it and how can we proceed to mitigate it.
+
+for my part i think it comes down to the "instance" model. no one cares if you have to ban someone from a building, but evicting them from their house or expelling them from their country is disproportionate. so naturally, it becomes an issue when the "community" and "living space" are the same thing.
+
+every day more and more it becomes clear we need to restructure around actual communities at a separate layer.
+
+similar to the dynamics of a cliquey community instance, but without the expanded audience that federation brings. imagine just turning off federation.
+
+maybe in some ways that's exactly what is going on -- clique communities are feeling threatened by the inherent lack of control. overblocking is in that vein similar to defensive centralization; after all, what is centralization if not simply blocking *all* remotes? and the balance is set by how much control they want to wrest back.
+
+i think the "objectionable" part to me is that clique mentality. especially as it tries to assert itself over others. the other day i had someone ask me which instance to join and i realized for the first time in 6 or 7 years that i didn't have an answer. they just wanted to exist. they didn't want to have to care about border controls and digital embargoes. and they didn't really have *any* good options.
+
+there isn't really any well-connected generalist instance that isn't overly blocked or doesn't overly block. much less an art-focused one. or a fandom-based one. so they stayed on tumblr and discord even though they *want* to join fedi. there just isn't anywhere for them to find a home in an area that is both good to live in *and* free of HOA type behavior. they don't want a gated community and they don't want a place with drive-by harassment. and they want to actually reach people.
+
+> [I] suspect that the reaching people, the lack of harassment, and lack of blocking are kind of corners of a triangle.
+
+yeah it certainly does seem like a trilemma
+
+instance moderation is absolutely a huge job if you want to stay on top of it. it can be easier if you take a reactive rather than proactive stance. but the problem with proactive stances is that you now need to judge someone *before* they have harassed you. and the way people approach recommended blocks, they might not have been harassed either. you'll never know the difference unless you investigate for yourself... and that's hard rn.
+
+now, if people just said "hey we dont like them, they failed the vibe check and we're not gonna spill any tears", that's more respectable than making something up. i can't count how many times i've seen people blocked for reasons that are patently absurd if you know the people. you use a reclaimed slur, you get blocked for using slurs. somewhere along the line that becomes "hate speech". a while ago it was "federates with the usual suspects". guilt by association morphed into "alt fedi"
+
+the hard part is... they're not always wrong! a lot of blocks make sense when you look into them. but it's a mix, and the false positive rate is a bit too high imo. and there's no indication when you lose friends over your admin's decisions. and the policies aren't always visible, bc some admins are hiding them now to prevent scrapers tracking them. it just becomes this whole uncertain mess where you never know who blocks who and why.

content/_dump/fedi-critiques/context-unaware.md

@@ -0,0 +1,29 @@
+i am more and more taking the position that we should have forums, and we should have blogs, and nothing in between. "social media" carries inherently poor ergonomics and a lack of clarity of purpose. you're never clearly "publishing" anything when you post on social media, unlike when you post on your own blog or website. you're never clearly "discussing" anything either, because threads aren't actual topics or conversations.
+
+so my ideal flow is kinda like
+
+- you make a "post" to your website/profile
+- it may or may not be "in reply to" some other post. this is just metadata
+- it may or may not be part of some "context". this is a moderated conversation or logical grouping owned by someone
+- the "audience" is up to you, completely arbitrary. it might be only visible from within the context of some other webpage, or it might be given a permalink on your website/profile
+
+fedi dropped the ball hard on those last two...
+
+we could realistically move toward something more context-and-audience-aware but it's gonna be a bit rough for the existing "instance" model because of structural limitations. you'd basically be building a new fediverse in the shell of the old. but i think it can be done...
+
+one prong is to support actual "publishing" with articles and a more fleshed-out web profile as a website. add webmentions as an optional thing.
+
+the other prong is to support "discussing" within walls/forums/rooms "context"
+
+eventually this kind of "posting" we have today would be split up and merged into the two new things. the UI would give you an option: do you want to publish a Post, or do you want to start a Discussion?
+
+---
+
+in my mental model. i have the following areas mapped out:
+
+- Publishing (posts)
+- Reading (feeds/timelines)
+- Discussing (forums)
+- Messaging (chats)
+
+all of these are types of communication, and naturally some apps are going to expand to cover more areas. but it's all dependent on context and presentation. a "chat room" and a "forum topic" and a "social media wall" are all just collections of objects, really.

content/_dump/fedi-critiques/default-server-paradigm.md

@@ -0,0 +1,13 @@
+https://mastodon.social/@trwnh/110310774875374491
+
+re: mastodon and matrix having "default servers" that end up being too big: i feel like if they were easier to selfhost it would be less of a problem. the "default server" paradigm is more effective when you can't easily set up other servers.
+
+you ever try to host matrix? it's awful. like 2GB memory usage just for a single user in a big room.
+
+mastodon is getting to be pretty similar, not because of the base software per se, but because of how many moving parts it has and how much resource usage accrues as a result. rails, postgres, redis, optional elasticsearch if you want working search, a nodejs streaming server and frontend... that's before you even get to the network traffic due to architectural decisions
+
+sure, but you can at least block entire bad servers with little-to-no collateral damage. and you can also use allowlist federation or some other restriction mechanism to avoid fully open federation. just like avoiding fully open registrations.
+
+i've oft thought about an opt-in federation of instances that require human approval for registrations. or a closed "federation" in the irc distributed sense.
+
+it'll never happen because gargron wants more users, and approval-based signup makes a lot of disinterested people bounce before actually trying the software. but it's worth considering imo at least as a thought experiment

content/_dump/fedi-critiques/fedi-as-reformist-option.md

@@ -0,0 +1,45 @@
++++
+date = 2023-04-30
++++
+
+https://mastodon.social/@trwnh/110290827199480228
+
+nobody asked but i think fedi as a whole is actually kinda "bad" in the sense that it's holding us back from better things. it's like the "reform" option when we need radical change. and it keeps getting "worse". somewhere along the way we seem to have dropped the "blogging" from "microblogging", and what remains is incredibly muddled. contextual and ergonomic failure. we're copying "social media" and inheriting its flaws. ad-free and chronological ain't enough.
+
+see, we're all mostly here to just hang out and spill a stream of consciousness, right? but there are problems inherent to the structure. context collapse (or no context at all), misuse of the medium (doing a "thread" instead of writing an article), and so on. everything just goes into the square hole.
+
+i posit we can do better. but it's gonna require going back to basics and building out communication paradigms from the ground up. with thought given to effective communication, not profitability
+
+but. (and this is where i am afraid of shit-stirring)
+
+no one wants to do that
+
+the people working on fedi past and present seem mostly invested in mass adoption, and the way to do that is to keep building on broken foundations. and it feels kinda cultish at this point, like the goal is "success" defined by "growth", and it's a branding game, it's lip service.
+
+"mastodon", even "activitypub" itself, is seemingly about mindshare more than anything tangible.
+
+i don't particularly want to call out specific people for this, because it's not just a few people, it seems to be a cultural issue. the framing is that we can replace those social media platforms instead of tearing them down as we ought to. mastodon wants to become the next twitter. pixelfed wants to become the next instagram. and so on.
+
+on some level i think the people are just looking for validation of their work. but this leads to a kind of conservative outlook toward actually improving...
+
+yes, this thread could have been a blog post. that's part of the problem
+
+---
+
+i mean we stop doing "social media" as twitter and facebook made, and go (go back?) to clearly publishing and clearly discussing, as two separate things. remember blogs and forums? on blogs, you publish. on forums, you discuss. on "social media", this distinction gets collapsed. a "post" and its "replies" are all in this one big global context by default. who is the audience? what is the purpose? these questions don't have clear answers on "social media". corpos profit from this ambiguity.
+
+in "social media", the audience is "whoever we put this in front of" and the purpose is "an endless feed of posts for you to graze from". contrast this with the intentionality of cultivating your own audience, and of communicating with them. fedi gets us halfway. we move away from the profit-oriented mindset, but we keep the trappings and mechanisms that were created in service of them.
+
+tldr we're on the Web and we should remember that. death to "platforms". empower actual people to set up their own spaces and domains.
+
+---
+
+there is an argument to be made that the right thing would not have been made clear if we hadn't kept making mistakes like chasing the big corporate players. i'd be open to this argument 10 or 15 years ago around the time of identica or diaspora, but since then it's just become more apparent that this whole space will never be anything more than a transitional holding-place for people who leave the walled gardens for... fenced gardens, i gues? and the better thing hasn't been built yet.
+
+---
+
+here on the World Wide Web you have two threats: capitalist enclosure, and toxic community. and honestly the latter is probably less bad, because at least you have the self-determination to make your own community with your valued friends if the current one gets too bad. with the former, you have no escape.
+
+in short, "social media" is a failed model invented by capitalists. what we need is a "social web". focus on people, not "content".
+
+want to entertain yourself? that's fine, there can be media hubs and curators for that. but your communications and your media consumption should be separate.

content/_dump/fedi-critiques/implicit-vs-explicit.md

@@ -0,0 +1,35 @@
+the way to maintain an authoritative collection is to send out Add/Remove, not to have everyone send out Create and then expect everyone else to reconstruct the collection for themselves
+
+i can't say i blame developers for taking the lazy route and doing the bare minimum to be compatible with what already exists, but that is so limiting and i'm not here for it
+
+the bigger problem is that there's so many assumptions being made with zero basis or foundation in anything. we're just replicating stuff around and then every server assembles it however it *thinks* it should be put together.
+
+we're getting to the point that the contradictions and shortcomings are starting to become more apparent...
+
+- things like moderated conversations are impossible if you don't actually have a concept of a "conversation".
+
+- there's so many different ways to do "groups" that it's a running joke at this point, because everyone has a different idea of what a "group" is. it's the "blind men feeling an elephant" problem.
+
+- things like forums and subforums, chat rooms, etc are not easily possible rn.
+
+the "trick" is that there isn't actually any difference between all these different presentations. if you understand "objects" and "collections" you can construct whatever you want: forums, walls, chat rooms, conversations, aggregators, whatever. it's all just objects in collections.
+
+right now, no one understands "collections". we just pass around objects with Create and Announce and leave it up to the consumer to figure out how they should be grouped.
+
+it's not even a new idea. Dennis Schubert raised a similar criticism of "replies" distribution back in 2018: https://overengineer.dev/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html#replies-and-interactions
+
+> As per the ActivityStreams spec, all objects [can] have a replies property. So, a more sensible, reliable, and even more AcitivityStream’y way of handling replies would probably be adding the interaction to the replies collection
+
+this is not always optimal of course -- it was proposed 5 years ago. but something similar could be done.
+
+i think the key disagreement, misunderstanding, lack of shared reality, etc, is this:
+
+are we just creating a bunch of "posts"? microblogging or regular blogging, we have our own websites or web profiles, and we only care about what we ourselves are sharing?
+
+or are we trying to collaborate across domains? are we building a Web, a Social Web, a Linked Data Web, a Semantic Web? where our actions have side effects, and there exists some state that we care about?
+
+we lack that clarity of purpose
+
+basically we're not doing one or the other, we're kind of mishmashing them together. when you post on most fedi projects, you are publishing to your profile locally, *but* you are also sending out an activity to notify your followers. and typically, that has side-effects on remote servers. usually that side-effect is "keep a locally cached archive of that post and show it to followers."
+
+i think we should be clearer about the separate use-cases and concerns.

content/_dump/fedi-critiques/mainstreaming-mastodon.md

@@ -0,0 +1,41 @@
++++
+date = "2023-02-02"
++++
+
+the shit i see on the mastodon issue tracker is driving me to just build my own thing because i honestly think whatever good culture mastodon has is quite possibly not long for this world
+
+some people literally just walk in and ask "why is this not like twitter" and demand that it be changed to suit their whims. and i feel like gargron is starting to take their side because gargron just wants More. old users be damned, they're just a vocal minority now.
+
+i mean, i wanna be wrong, but i don't actually think there are any guiding principles behind mastodon except "whatever gargron wants", so it is at the very least a possibility, if not a credible threat
+
+there was a post i saw earlier yesterday about something like, idk, i think biz stone said he was advising gargron, and one of the replies was something along the lines of how we should be "turning Mastodon from a small platform for the fringes and oppressed minorities to a platform that welcomes more mainstream members" and i legit shuddered while reading that. what a terrifying thought.
+
+on some level, sure, it's probably cool for "mainstream" people to have something healthier than corporate social media. but i'm really concerned that they'll ruin it for the rest of us, exactly those "fringe and oppressed minorities" who were here for years. years ago we talked about the sort of "detoxification cycle" that new users would go through, and with every new wave, people acclimate less and less. they import more of their old behaviors uncritically.
+
+ultimately? i think things will probably settle in at a point that's better than others but worse than it could have been.
+
+this exact kind of mentality by newcomers who feel entitled to influence
+
+> you don't owe the top of the pyramid jack squat. The early movers *need* you more than you need them.
+
+if i may be so frank, can i just say: we don't "need" you *at all*. our experiences are rich and valuable and span over half a decade. you're certainly welcome to be around here, and you're welcome to use this software, but you have no right to demand we center you above ourselves.
+
+also the idea that there's some sort of "secret mastodon development cabal" is ridiculous. for better or worse, there's gargron, and i guess in some ways there's claire, and that's about it. everyone else is simply acting independently in their own interests and on their own agendas. the entire reason i worry can be summed up by the fact that gargron has unilateral decision-making power and final say. but, to his credit, he does consider the consequences.
+
+anyway, anything i say is with the disclaimer that i am not a representative of anyone else, but perhaps i should be more overt and assertive about it. when i say something "without 100% certainty" i am not implying a vague recollection of events, i am only indicating that i have no decision power.
+
+tangentially, the real problem with these design decisions in mastodon is that they're inconsistent, precisely because it's all on gargron, and gargron is not strongly in favour of these decisions. it all depends on the feedback and advocacy of community members to convince him to do anything, and then he'll do it however he wants to or ends up doing it.
+
+real consistency? we'd not have numbers in explore/trending either, nor on detailed status views, nor in api. no "1+". it'd probably be some boolean like `has_replies` or something, which translates to an icon indicator to show the thread.
+
+but doing it that way takes commitment. it takes decisiveness. and that's simply not there.
+
+there's a lot of these scattered around the project codebase -- places where gargron wanted to do something one way, a lot of the community had to vocally disagree, and we ended up with a half-measure
+
+there was a similar case around hiding your follower counts, where gargron decided to only allow hiding the contents because he thought follower counts were important signals of account quality. even though the counts can be faked (and they have been!)
+
+once again, though... you have to give the guy credit for not rejecting all this outright. it's the only reason we ended up with anything better than twitter instead of Yet Another Twitter Clone.
+
+to quote someone anonymously:
+
+> i don't like a lot of the decisions mastodon makes but i god damn respect "we have a philosophy and that's why we are doing it that way" in particular if the philosophy is thinking carefully about how decisions affect the minority

content/_dump/fedi-critiques/nation-stateificiation.md

@@ -0,0 +1,5 @@
+oh right i forgot we live in a geopolitical climate of tens of thousands of digital nation-states each with their own culture and borders. for a second there i thought i was using a general communication service
+
+anarchist, but against fediverse "instances"
+
+the dilemma of fedi is that i don't want to host my own service using current software, but i don't want to be judged by whose service i use or by who else uses that service

content/_dump/plaintext-xml-json.md

@@ -0,0 +1,8 @@
+actually it's kinda interesting how every single spec largely breaks down along one of three ideological lines: plaintext, xml, or json
+
+i'm seeing a general analogy between DNS, XRI, and Webfinger resolution
+
+- DNS returns a plaintext answer
+- XRI returns an XRD
+- Webfinger returns a JRD
+

content/_dump/services-vs-communities.md

@@ -0,0 +1,13 @@
+https://mastodon.social/@trwnh/110329802576726213
+
+services aren't communities
+
+the gmail community
+
+imo the biggest mistake of fedi is tying together the social and technical layers. local timelines should have been group chats all along
+
+it's a huge misunderstanding because some people want services and some people want communities and they are not the same thing. some people can run a community but offer bad service. some people offer great service but can't run a community
+
+instances shouldn't exist as the only model. the service layer and the community layer should be separate. combining the two makes both of them worse -- as can be seen if you violate the rules of your community, you lose access not just to the community, but to the service entirely. and if the community cannot continue to provide service, you again lose both.
+
+i do think there is some value in being both, because then people feel more likely to donate as they are personally invested. but you could have incentives to donate even while keeping them separate.

content/_dump/shorts-are-too-long.md

@@ -0,0 +1 @@
+i fucking hate the "shorts" format. vine was okay purely because it was limited to 6 or 7 seconds -- if you're going to take away the video controls, prevent me from seeking, maybe autoloop? then i am NOT sitting there for a whole minute while you fail to get to the point. i'm not doing more than 10 seconds, maybe 15 seconds at the most. anything over that should let me seek through the video!!!! videos should always be seekable but if you're not going to make them seekable then at least limit them to one coherent logical "moment"

content/_dump/social-media-failure.md

@@ -0,0 +1,7 @@
+the more i think about and research communication paradigms, i'm starting to think more and more that this whole "social network" thing is just fundamentally flawed. in pure terms you might send a message or publish a resource. but with these social networks it's not that clear cut. you're never unambiguously sending a message or publishing a resource, but instead, some weird hybrid that we call a "post". not quite message, not quite resource. it exists in part or in whole exclusively on-network
+
+and i guess that makes it easier to put in a silo which is how companies maintain their profit motive.
+
+but in replicating the design of these social networks we replicate their properties too. fedi hasn't entirely moved past silos because it's embedded in the design level. thankfully not the protocol level, but still. it's going to persist in implementations as long as we limit ourselves to "twitter but better", "instagram but better", etc. we're not building the commons that we could build.
+
+and the lack of clarity in our metaphors and associated abstractions leads to subtle violations of what people expect. there should be a clearer split. consider the duality of tumblr as both a social network and a publishing platform. they're making this split more apparent than it used to be. in addition to username.tumblr.com for blogs they now have tumblr.com/username for network profiles.

content/_dump/social.md

@@ -0,0 +1,83 @@
+is2g ifwhen i make my thing i am going to put a lot of effort into a filter system that actually makes sense. i will not be supporting "mute" or "block" as binary features, but rather, everything flows through the filter system. mastodon filter v2 system is an improvement but doesn't go far enough
+
+---
+
+in any case yes it would be better to encrypt everything or just not peer/replicate at all. fedi has a problem with this because for some unknown reason we all decided it would be a convoluted distributed state machine which is a bad idea when you don't trust all participants, and also worse when those participants are explicitly redistributing it while attributed to you. at that point you might as well go all-in on syndication rather than federation. put another way: federation makes sense for message passing but not for publishing (and fedi is an awkward and unclear hybrid between messaging and publishing)
+
+---
+
+idle thought: idk if i care so much about "fedi" as much as it is "people who are on fedi". either in the abstract or in the concrete, i just wanna make friends and talk to cool people. fedi is little more than a place for fateful encounters based on the streams of consciousness we put out there. the important thing is that no one meddles with this for profit or otherwise. the second fedi stops providing that, i'm out.
+
+it's a big part of why i don't really relate or sympathize with people who just want fedi to grow. i think any growth has to be sustainable. the values are valuable. if the values are compromised then fedi isn't valuable to me anymore.
+
+note that there's a big distinction between this and communicating with people you know. if some people are only on fedi then that has a different type of value. network value is not the same as the value of the network.
+
+it's always the people, i'm only here for the people. i do not want to keep track of the diplomatic politics of tens of thousands of nation-states. no one should! we made a wrong turn somewhere back in 2017 when people started making "community" instances, and arguably we were on the wrong path from the very beginning. maybe the whole thing is wrong tbh. we need to go back to actual forums. the ergonomics are all wrong. the model is wrong. we're just trying to mash everything roughly into the shape of twitter. and worse, every twitter has its own culture and community and is assumed to be homogeneous! how do you atomize all this? 
+
+---
+
+[asking natalie what should be removed or what is missing from misskey](https://mastodon.social/@trwnh/109958119755489250)
+
+<blockquote>
+
+i like that it's an outsider take on fedi and is not afraid to push boundaries and go beyond what mastodong has envisioned
+
+what's missing is muting/blocking actually being functional. i'd also like to see Room come back lol
+
+what should be removed: basically nothing. maybe proxy accounts. if i wanted minimal i'd go use some useless software like honk, misskey maximalism is actually really fun
+
+</blockquote>
+
+---
+
+the general objection is "that's not how we currently federate", as if the way we currently federate should be preserved forever
+
+---
+
+"relays" on fedi are like the worst possible interpretation of relays. imagine one big irc room that has no topic whatsoever. just thousands of people posting whatever they want. why
+
+also imagine your irc client had autologging turned on, and didn't have an easy way to clear specific logs
+
+---
+
+this shit should be generic and it can be browsed by a social web browser or a linked data renderer
+
+i think it makes the most sense to lean into the Web and just focus on making the publishing as easy and straightforward as possible. i think most people (ideologues aside) don't actually want "federation" as commonly thought of. in absolute terms they want their posts to show up in a reader.
+
+there still is a place for federation, the "federation" i'm interested in is more like replication in a distributed database. and i'd like to link it all up across domains like "nomadic identity".
+
+example: imagine a network of generic servers
+
+your server shuts down, you walk up to any server that has your posts already, prove your identity, pick up like nothing happened
+
+basically you should be able to "claim" your federated profile on other domains, kind of like how on a centralized site you can claim your profile page if you're a celebrity or whatever
+
+nomadic identity is literally just doing this process yourself beforehand by setting up mirrors/replicas of your key
+
+---
+
+i forget who it was that said "a single timeline is unsustainable" (aaron parecki?) but i'm feeling more like the real cardinal sin is publishing to a single profile. i don't mind *reading* everything in a single view, although making lists certainly helps. it's the *publishing* that annoys me. i almost *never* want to send a post to *all* of my followers. and this goes doubly for replies. i often want to reply within a specific context and only *optionally* tell my followers about it.
+
+"one account per feed" is a goddamn travesty. an account should be able to have multiple profiles, and a profile should be able to have multiple feeds, and you should be able to follow individual feeds instead of being forced to follow an entire profile.
+
+yeah, i was thinking similarly. except i was going to make Collections into actors that could be followed. which would be incompatible with mastodon, because mastodon assumes wrongly that actors must be exactly one of The Five Types. but then again, i am somewhat losing interest in this whole "social media" thing and would prefer to focus on a purer model of publishing web resources and managing them with collections. so maybe "mastodon compatibility" is not all it's cracked up to be...
+
+if anything, i was thinking of treating "mastodon compatibility" similar to a crossposter up until such point that mastodon relaxes or removes its unnecessary type-checking. you'd have an actor that you can send your activities to, and it will translate them into mastodon-flavoured activitypub and deliver out that translated copy. this actor would have its preferredUsername and all that compat stuff.
+
+---
+
+btw i think that deletes being so costly is something that is entirely a consequence of having essentially replicated the data with a ttl of forever. that's the default mode of every "fedi" software. it makes no sense for most people and it stems from the ideological decisions of over a decade ago
+
+by which i mean: there's a word for having your published content be replicated to other sites, and it's "syndication". we had this technology for really simple syndication... rss. it later evolved into atom. the "fediverse" was founded on ostatus built on atom feeds. when we say we're "federating" we're really more accurately "syndicating". you just don't have control over the accounts being created on other domains, on your behalf.
+
+i keep talking about how the metaphors are wrong, like how we merged the concepts of publishing and messaging to the detriment of both. we're sending messages that contain the entirety of a resource that we meant to be published. of course it's going to lead to outcomes that don't make sense. maybe one day people will understand this
+
+also... authorized fetch won't solve this. if you have a password protected blog, and someone is saving every new post and republishing it, and you let this happen continually, then what's the point of the password?
+
+---
+
+i think it's very important that users be able to understand and reason about the software that they are using! when it "does the thing", it should do so predictably.
+
+the argument for generic AP is that generic AP allows you to manage resources predictably, without having to care what others will do. it's a standardized storage layer. without it, you need a mastodon account, a pixelfed account, etc... every "platform" owns your data separately.
+
+imagine if switching from outlook to thunderbird necessitated losing all your emails and maybe even your contacts.

content/_dump/w3c-http-supremacy.md

@@ -0,0 +1,16 @@
+https://mastodon.social/@trwnh/109886416964217719
+
+reading a lot of old w3 literature and while there's a lot of good stuff in there, it is *infuriating* how they are so blindly in support of using http for everything, including identifiers. they probably just failed to predict the future, but they keep stopping just short of admitting http's biggest problem: when the server goes down, your uri can't be dereferenced anymore!
+
+(specifically i was reading https://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml which argues against urns because you can't dereference them)
+
+am i being too harsh on an editorial from 2001, sure, yeah, probably no one was seriously thinking of decentralized systems back then. if you just wanna obtain a resource from a given organization or whatever, it is generally a given that the org has its own domain name and can assign ids on that domain. but the whole thing falls apart when you need a global namespace that can be requested from multiple domains. this is *exactly* where urns are useful! like, naming things is in some way id!
+
+if we follow the logic of http maximalists from 2001, then we would not need the isbn or doi namespaces, we could just assign identifiers on an http hostname. a doi can be resolved using an http url so why not just use the url directly?
+
+well, that assumes persistence that simply isn't guaranteed. the doi foundation will tell you itself: https://www.doi.org/the-identifier/resources/factsheets/doi-system-and-persistent-urls
+
+> PURLs are all http and inherit both the strength and weakness of that approach
+
+it's those weaknesses that kept being ignored
+

content/_dump/webfinger-as-dns.md

@@ -0,0 +1,53 @@
+https://mastodon.social/@trwnh/110361352685140966
+
+so we might reasonably recreate bluesky's "placeholder" nameserver by having a well-known endpoint for resolving identifiers to as2 documents (with possibly a layer of indirection, in which case webfinger would probably work)
+
+this basically replaces DNS for resolution. you'd just have to figure out how to assign ids in a distributed way without conflicts
+
+for that matter: why isn't xrpc a .well-known endpoint? it absolutely should have been
+
+i'm thinking if we wanted to reify webfinger and identity providers, we could just have identifiers assigned under the authority of webfinger subjects. where is the data? idk, check the current links via webfinger.
+
+problem with that is, your IdP better be long-lived... in fact, it makes sense for a persistent IdP to last basically "forever" and just point to your current data stores. and then i guess you'd want IdP federation to ease migration between IdPs? or otherwise conflict-free id minting
+
+tldr the open problems:
+
+- how to assign ids without conflict? (preferably without dns or key based authority, so you can change those later)
+
+- how to resolve those ids across multiple servers without tampering? (see also: dns poisoning and authoritative nameservers)
+
+there's a lot of prior art in DNS and you'd be moving it all down to the HTTP level over webfinger and oidc and related stuff
+
+basically instead of resolving names -> authoritative DNS nameservers -> IP addresses, you have to resolve uh... names -> authoritative Webfinger servers -> http(s) links
+
+so i guess we need an equivalent to DNSSEC but for WebFinger
+
+---
+
+erincandescent writes:
+
+<blockquote>
+
+hash of public key; hash of first version of document (in chain), like they did. many decent options!
+
+the did:plc approach allows you to rotate keys because your current identity document will eventually chain back to the original one which hashes to the value of your account ID
+
+the bit the central server is doing in this system is - basically - ordering things & letting you use your recovery key to oblitterate any updates from your primary key from the last 72 hours (for if your primary key was compromised)
+
+the key difficulty without any central server is timestamping things to ensure & validate ordering
+
+</blockquote>
+
+cobaltvelvet writes:
+
+<blockquote>
+
+i think i just like the idea of a minimal relay as this resolver, that would keep the least state possible inside it, so it can be swapped in and out easily, maybe even transparently so by your instance. but it would always need A Way to validate the 'latest location', either the keypairs that arent very securely held atm but instances already have, or a third secret thing (a dedicated channel, like making the resolver email you to confirm a migration, or another layer of signatures)
+
+if i had to point to an inspiration, i think bittorrent trackers are great, easily replceable by a DHT, but also easy to just use two for redundency . ofc they don't really have to bother with any validation, but your instance can
+
+</blockquote>
+
+---
+
+i'd just need to think through how to get consistency between different webfinger services, so that they agree on the response and serve you up the same JRD from some decentralized/distributed data store

content/tech/spec/activitypub/confusion/server-managed-collections.md

@@ -0,0 +1,15 @@
+There are special collections that are managed by server side-effects, such as `followers` `following` `liked` on actors and possibly `replies`, `likes`, `shares` on objects. In most cases, the side-effects are the only intended way of interacting with these collections; for example, a Follow results in an Accept Follow, which has the side effect of adding them to `followers` and them adding you to `following`; a Like has the side effect of you adding the object to `liked` and them adding your Like to `likes`; an Announce has the side effect of them adding the Announce to `shares`, and a small exception for `replies` which may be managed manually.
+
+But there's nothing in ActivityPub explicitly preventing a user from targeting their followers/following with an Add/Remove. In the case of a Remove, you can say that there is a legitimate use-case for this; perhaps you no longer wish to follow or be followed by a certain actor. However, for Add, it's a bit weirder -- you can Add an actor to your `followers` despite never receiving a Follow from them. You can add an actor to your `following` despite never receiving an Accept Follow from them.
+
+There is some language that can be interpreted along these lines, in 6.5 Follow 
+
+> The Follow activity is used to subscribe to the activities of another actor. [...] The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's [following Collection](https://www.w3.org/TR/activitypub/#following) when and only if an Accept activity is subsequently received with this Follow activity as its object.
+
+and in 6.6/6.7 for Add/Remove:
+
+> the server SHOULD add the object to the collection specified in the target property, unless: [...] the object is not allowed to be added to the target collection for some other reason, at the receiving server's discretion. 
+
+Taken together, we conclude that the logical `iff` regarding Accept Follow is the only way to add the other actor to your following. A C2S Add/Remove would not be allowed due to "discretion".
+
+Given this: how do we signal server management instead of actor management of these collections? My initial leaning would be to exclude `attributedTo` from the representation of these collections; in the absence of any attribution, it is assumed that the collection is owned by the server running at that origin / domain / hostname. (For S2S follower removal, this would have to be a special case handled similarly to Reject Follow being sent at any time after an Accept Follow, but that's a separate topic.)

content/tech/spec/activitypub/confusion/tag-for-actual-taxonomy.md

@@ -0,0 +1 @@
+in theory `tag` is for "association by reference". you reference other nodes, which can be either objects or links. but what's the best way to reference an arbitrary string? there is the unofficial extension of a `Hashtag` but this ends up getting used as a signal to show your tag alongside other posts that share the same tag. also the format of hashtags is a little weird -- no one can really agree on it. does it contain the hash sign? is it allowed to contain spaces? is it a subtype of Link, or a subtype of Object? should it or should it not appear in the content, since `tag` seems to be used to markup microsyntaxes?

content/tech/spec/activitypub/ideas/jokes/Poke.md

@@ -0,0 +1 @@
+inspired by facebook pokes or by Yo. just sends a notification. transient, no id.

content/tech/spec/activitypub/ideas/jokes/forum-signature.md

@@ -0,0 +1,5 @@
+https://mastodon.social/@trwnh/110252106080079481
+
+maybe ive said this before but fedi should have forum signatures
+
+`signature` shouldn't mean proof of authorship by a keypair. it should mean a 460x120 image and about 1-3 lines of text