Blygger
27 Sep 2026 - 30 Sep 2026
- new vgr blogging protocol
what is it
- a decentralized public writing medium
- built on static files and RSS.
- AI friendly but not part of the protocol
blyg
- directory of files at a publisher domain
design invariants
- blyg is static files
- RSS feed always valid
- AI not in protocol
- identity not in protocol
development pathway
Immediate
- Need to make blyg deployment easy, automatic, fast. More Like AskClaude than goddinpotty. Or could do both I suppose.
- Yes make Blygger plugin
- Blyg's current block and children
- Paramterized with publish endpoint, it's really trivial.
- I suppose it should get an id back and store it in the block.
- But i don't have a blygger publish endpoint, would have to build it
Longer term
- I need my own stack, at least for writing if not reading.
- GardenParty for real
- Retain Logseq as writing surface
- Automatic publishing to a server with a live block database
- seems like overkill, all you need is a local db and incremental updates
- Server needed for publishig, maybe
what I should do with it
- AMMDI/goddnipotty link somehow
- ammdi. hyperphor com/blyg
- Unclear how this should interact with other content
- Announcement: My blyg is up at AMMDI: AMMDI Blyg . It's done as an appendage of my digital garden aka personal wiki site, which I hope is an interesting variation. Ever since I started AMMDI, I've been fretting about the fact that its lack of a temporal feed makes it completely out of sync with the world of feeds, and dreamed of various ways of adding that on...so this finally pushed me over the edge. I haven't done the obvious thing yet which is to publish blyg-fragments when a wiki page changes, that's not hard but it might be too much, I'm trying to think it through first.
Design critiques
None of this adds a reply primitive. This remains a network of soapboxes: public speech that cites, and citations that can be checked.
- The anti-conversation bias just seems stubborn and idiosyncratic to me. I mean it's his protocol and he can design it how he likes, but replying is a pretty basic concept and people will add it in if it isn't there (already happening I think>)
What a stub is not: a reply. There is no thread of replies, no conversation object, no notification to anyone but the target's origin, and nothing a target can do about being stubbed except read it. The stub is on the stubber's soapbox, under the stubber's identity, in the stubber's feed.
- OK I am completely confused about the status of "replies" in Blygger. The 0.3 spec says both "a stub is a response" and "a stub is not a reply". I don't understand the difference. And if its too obscure for me to grasp it probably needs to get clarified if this is going to be a widely-shared protocol. blyg blygger-spec/docs/protocol-v0.3.md at main · blygger/blygger-spec · GitHub
- will blyg about this in hopes of a response if not a reply haha.
- I suppose this is an aspect of the design principle "this is a network of soapboxes, not a conversational medium". I not only don't like this rule, I think it's incoherent, as the confusing language indicates. Are you trying to technically legislate non-arguments? I suppose a lot of that kind of thing is tedious and boring, especially when it is across ideological lines, but calling it something else probably isn't going to help.
- Oh actually I just figured out the difference (I think): "reply" denotes a kind of 1st-person style of direct argument, where person A and B are talking back to each other. "response", or citation, implies that you are talking to a 3rd party about a 2nd party. A is talking about B to C, where C is the audience. Isn't there a senate rule about that?
- Ask Claude
- Yes, you've hit on exactly the right analogy. Under Senate Rule XIX:
- All speeches must be addressed to the Presiding Officer. Only the Presiding Officer may be directly addressed in speeches; other members must be referred to in the third person.
- In most cases, senators refer to each other not by name, but by state, using forms such as "the senior senator from Virginia" or "the junior senator from California."
- So the structural logic is identical to your reply/response distinction: a Senator never directly addresses a colleague on the floor — they speak to the Chair about the colleague. Senator A addresses the Presiding Officer (C) about Senator B. Direct second-person address between senators isn't the form debate takes...
- That seems like a crisp way to clarify the spec. The distinction is real and meaningful — it might just need a sentence in the docs that makes the rhetorical direction explicit, perhaps something like: "a stub is addressed to readers, not to the author of the cited post."
- Hm maybe, I think it needs better naming or it will cause a lot of confusion. Why not "citation" as the primitive if that is what they are? It was explained to me as like quoting a tweet, so maybe call it a quotation?
Trying to catch up
- There's a new Discord channel and way too much to priocess
- GBG mention
- Kyle matthews Blygger Studio (that was fast) blyg-pin
- Got it running, some notes if they care
- I don't really understand this tk stuff. I mean it is the equivalent of /AskClaude but it doesn't do the wrapping, and doesn't have fine-grained control (but it DOES have the ability to add extra prompt which is obviously good (although in Logseq you can just add in the text why not))
- Not actually sure how it handles the prompt, lets see...
- publish button has no feedback (or is broken) oh it had an error (at the top where you couldn't ee it)
- Cannot publish: fragment exceeds 1000 characters. Well then why did you generate a big chunk of text?
- OK figured out the [TK] syntax, wasn't obvious. So it DOES retain the prompt, that's good. And in a more structured way than I have been doing with Logseq.
- The published version doesn't include the prompt or any indication of AI-generation. Which I guess can be a choice! SHoudn't be the default though. (Looks like the protocol supports this fully so this is a reader choice?)
- Subscription
- The resolve step in subscription is unintuitive and no feedback?
- Allows duplicates which are a pain to remove.
- Reading
- Somehow all of these blygs look kinda unpolished, but I suspect that is deliberate.
- no feedback on thumbs up (and, I realized later, this is not like a like button, its purely local and never gets shared)
- A refresh didn't pick up Venkats latest. Not sure what the mechanics are or how long updates take to percolate. (and needs a refresh button if it isn't automated)
- Responding
- OK it is so fucking weird not to have any kind of reply affordance. I mean I guess I can understand. But it would be trivial to add something reply-like without changing the protocol, so why make it go underground? I'm sure this is discussed somewhere.
- This is on venkat blyg, should check out others
- Weird Kyle somehow responded to a blyg of mine, in a thread with just an eyeball emoji. But he is using the same software I am...I'm confused 👀 Huh Apache getting into the ontology business Home - Apache Ossie (… — Kyle's blyg
- What you can do is transclusion. But the frag selector seems borked, only showing me entries from one blyg and not the one I ased for.
- Random
- All of the above activities are quite independent of each other, and I think the protocol design wants to think of them that way. So they don't all need to be bundled in a "studio". Although it doesn't hurt for convenience, it might give people the wrong idea
- There should be at least a link to the studio from the public page, if only in dev mode! Argh!
- Sep 29th, 2026
- To Blygger discord blyg-pin this hopes to turn into a thread
- A few random thoughts
- (1) the technical design values of Blygger seem very old-school, Web 1.0 (not meant as criticism or praise, just an observation). No more centralized platforms, everybody acts as their own publisher of static content, the way Tim B-L would have wanted it. blyg
- (2) the user level design values are explicitly biased towards a particular model of communication. I'm not sure I share those biases, but it's your design so not going to argue about that (unless you want to). But it raises a kind of meta-question about protocol design, should something at this level be as general as possible (which probably would help adoption) or tuned to particular use cases? blyg
- (3) The [tk] stuff is neat but seems mostly orthogonal to the rest of the protocol. It could be split out as a general markdown/html extension. blyg
- (4) scaling issues. eg index.json is defined to include every item ever published. Should I put my 27K published wiki blocks into it? Probably not! But (a) would be cool if I could and (b) if this is heavily used, in a few years everyone will have the same problem. blyg
- Sep 30th, 2026 blyg-pin
- Implementing threads and pinning so Venkat can reply to some of the stuff above.
- I have to say I Do Not Get the design philosophy here. It seems like it is trying to make responding as awkward and difficult as possible. So – Venkat wanted to respond to something I had written. Yay, dialog! First I had to implement threads, but that's OK. But then he tells me I have to pin it so it can be forked so others can include it as a quote.
- So someone who wants to respond to me has to ask me through a side channel to pin my post first? You gotta be kidding (note: I may just not understand the model here).
- The alternative seems to be to pin everything by default, then you get a Twitter-like model where posts are immutable. But that seems to be discouraged.
- I'm pinning this because I'm interested in responses, and its not the sort of thing I'd be likely to want to revise.