<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>flak</title>
    <link>https://flak.tedunangst.com/</link>
    <description>flak rss</description>
    <managingEditor>tedu</managingEditor>
    <image>
      <url>https://flak.tedunangst.com/icon.png</url>
      <title>flak rss</title>
      <link>https://flak.tedunangst.com/</link>
    </image>
    <item>
      <title>enterprise social</title>
      <description><![CDATA[<p>The Honk Foundation is pleased to announce the initial release of Enterprise Social, previously known as Honk Enterprise, previously known as honk3. It’s reworked and retuned, reimagined and remade. A social network for the future.<p>I wanted to rewrite the honk frontend for a while, just to try some new things, but the changes would only be visible to me. Showing it off would require letting users create their own accounts. But I have no interest in hoarding your data. The only migration technique that effectively works is hostname based, which requires vhosting support, making everything a bit more complicated. And the original honk code is not very efficient at multihosting.<p>What started out as a frontend project turned into a from scratch rewrite of everything else. But it’s finally, mostly, done. So grab a <span class="smallcaps">CNAME</span> and check it out.<h3>what</h3><p>Enterprise Social is a server for a federated social network. Using the ActivityPub protocol, it communicates with other servers running honk, azorius or flak, or even humungus or mastodon. It supports displaying and interacting with microblogs, macroblogs, discussion forums, and version control commits.<h3>ambitions</h3><p>Honk makes some effort at dynamic page refreshing, but it was a late addition, and never entirely complete. Many actions trigger a full page reload, which isn’t too bad since it still reloads fast enough, but it’s wasteful as all the old posts have to be resent from the server to the client. I wanted to build a new interface which wouldn’t lose state, and only load required data.<p>Another issue is that I have a number of overlapping lists. Got the coolkids, the techbros, the bigbrains. Switching between them results in many posts being sent two or three times. It would be better to only send the identifiers and have the client fill in the timeline.<p>A quick test revealed that client side rendering can be very fast. Not sure how all these sites manage to make it slow, but not my problem. The server can help the client by tracking which posts the client already has when it responds to requests.<p>So that was the big dream. Well, still is. But abandoned it in favor of the old model of server side rendering and having the client just swap contents. I was changing the data model on the server too frequently, which required a client side update, and there was just too much in flux.<h3>reality</h3><p>As soon as the prototype front end was done, it needed a real backend to work with. This is fine. I’ve done this before. But second system syndrome sets in. Most of the code was actually copied from azorius, the previous second system, but reworked again.<p>Lots of little changes in design had consequences that required more changes, with more consequences, with more changes. As one example, honk was designed to be very forgiving of missing or corrupted data. There’s no need to actually check the author of a post. It’s just a URL, stored as a string. I decided to change this to a number, personid, joining against the persons table. So now it’s imperative that a person row exists. Similarly, if a post is a reply, we can reference the parent as URL, as honk does, or make it a postid, which requires that it exist. But if these objects can’t be fetched, what to store in the database?<p>I think I’ve got it sorted out now, but it took a few schema iterations, which weren’t supposed to be taking as much time as they did. The result is the frontend got enough attention to be functional, but not fantastic.<p>A lot of existing features from honk haven’t been reimplemented yet, but they’re on a roadmap somewhere. I should make another post listing all the differences, both additions and removals.<h3>features</h3><p>The Honk Enterprise Brand Safety Council is pleased to announce an exciting new triangle avatar design that combines the familiar comfort of stable and reliable shapes with the promise of dynamic fun with its playfully skewed lines.<p><img src="/images/tritar.png"><p>Part of the frontend rewrite that has started going well is a redesign of the look. The old honk didn’t really look like anything, so I decided to lean into a style a little more. There’s a few looks available now. Cyber, paper, and amber. Only enough to establish a general art direction, but now I have something fun to noodle with for a few weeks.<p><img src="/images/honkcyber2.png"><br><img src="/images/honkpaper.png"><br><img src="/images/honkamber.png"><p>There’s also an advanced &lt;video&gt; player builtin.<p>Despite the total failure to really get anything done as planned with the interface, the backend rewrite is more exciting.<h3>nomads</h3><p>With the fake news out of the way, time for the real news.<p>An ongoing issue for the fediverse is account migration. Servers go down, or admins become unruly, or whatever, and when the server dies, your account dies with it. There’s a Move activity, which doesn’t really do anything; don’t believe the lies.<p>The root of the problem is that your user@host identity is not just the user@ in front of the hostname, but also very much the @host part, too. (Technically, your identity is some https url, which definitely includes the hostname.) A number of proposals have been proposed using fancy directories and chains of blocks and advanced wizardry, which can be deployed just as soon as we rewrite all existing software. Or, what if, we simply leave the host part of the identity in control of the user as well, instead of piling multiple users onto a single hostname.<p>So that’s what Enterprise Social does. You pick a <span class="smallcaps">CNAME</span>, you point it at the server. When you want to move to another server, you point the <span class="smallcaps">CNAME</span> at another server. It’s so simple it may even work. Other software won’t even know there’s been a change.<p>The downside is there won’t be any cool blog posts with interactive diagrams explaining how it works.<h3>honk one</h3><p>So what’s the story with honk one? It’s not going anywhere.<h3>honk3.org</h3><p>I’ve got my instance set up at <a href="https://honkasaurus.world">honkasaurus.world</a>. Although it’s technically hosted by honk3.org.<p>If you’d like to see how bad things are, pick a domain name, point its <span class="smallcaps">CNAME</span> at honk3.org, then hit the signup page, wait a few moments for let’s encrypt to figure out what’s what, and it should be good.<p>Specifically, visit the <a href="https://honk3.org/login">login page</a> and create a user by entering user@domain.example.com into the signup form at the bottom. You can poke around on honk3.org (it’s all the same server, after all), but after about 15 seconds, visiting domain.example.com should work as well.<p>When you’ve had enough, you can export your data, and import into your own server. Well, assuming you want to continue running some flavor of honk, or something that permits import. A lot of supposedly free social network software has this weird attitude that it’s your data, but you can’t bring it here. <p>Import should also work, if you want off Masto Don’s wild ride, but maybe give it some time before asking about that.<p>I figure I’ll run the honk3.org server until I get tired of it, or something bad happens, and then you’ll have to move, but the good news it should be pretty seamless. It will always be your hostname, your identity.<h3>dev timeline</h3><p>This took a bit longer than expected, and still dropped the more ambitious aspects of it, but come on. There was a heat dome which required daily meming. I made a few posts hinting at progress along the way.<p><a href="https://honk.tedunangst.com/u/tedu/h/K895SFw2Hr17TDxbNQ">05 Apr 2024</a>: A brief experiment would seem to confirm that client side templating can be fast. Used handlebars.js to fill out a template with an array of 1000 elements, jammed it into the dom with insertAdjacentHTML. Instant. So far below measurement threshold I had to scale up to laughable numbers, and then the bottleneck became layout.<p>This was the first test to prove viability of the client concept.<p><a href="https://honk.tedunangst.com/u/tedu/h/PZ8Hycjcs47KrNHG1N">17 Apr 2024</a>: Scrum lord is asking why honk enterprise won’t be ready in a month, and my excuse is I’m over here stacking yaks.<p>At this point, I was busy adding ActivityPub support to humungus, so I could add it to honk3. So the scope of this project had expanded to first bringing up multiple other projects. That was a bit of a timing setback.<p><a href="https://honk.tedunangst.com/u/tedu/h/nJqfP6S1gc19GDFg2r">26 Apr 2024</a>: As a reminder, all statements about honk enterprise are forward looking statements, and users are cautioned not to place undue reliance on these statements.<p><a href="https://honk.tedunangst.com/u/tedu/h/dnSGNpBnN4nmXPMzHz">23 May 2024</a>: The release of Honk Enterprise has been delayed yet again as we investigate the theft of ideas and technologies by the Honk Freemium team.<p>This was about adding drag and drop support to the post editor. Got it working, figured honk could use it too.<p><a href="https://honk.tedunangst.com/u/tedu/h/n3zz8lynwP3l5gRDC3">06 Jun 2024</a>: Just received word from the Honk Enterprise Brand Safety Council that the new avatar redesign has passed initial review and is advancing to focus group testing.<p>Spent some time designing aesthetically pleasing avatars, so I think at this point I had enough of the app up that I needed to separate posts by different users. Also, it was fun.<p><a href="https://honk.tedunangst.com/u/tedu/h/yy9wFh149c1g388KQW">14 Jun 2024</a>: Honk Enterprise will not be launching next week, a decision that reflects our commitment to providing a trusted, secure and robust experience for all customers and gives us the opportunity to seek additional feedback prior to general release.<p>Pretty close to done here for the main features, but needed to add some filtering and configuration.<p><a href="https://honk.tedunangst.com/u/tedu/h/3CJk24T6S2dgPzhq33">27 Jun 2024</a>: The honk enterprise team is hard at work performing covert testing on an unsuspecting public.<p>Almost done. Switched focus to some more interoperability testing.<p><a href="https://honk.tedunangst.com/u/tedu/h/qgG3Gprp6M6Q9S9vP3">01 Jul 2024</a>: Honk Enterprise could not be released today because the lazyass PR team refused to work over the weekend and there’s no announcement ready.<p>Bought myself another day to finish up the let’s encrypt integration by finding someone else to blame.<h3>code</h3><p><a href="https://humungus.tedunangst.com/r/honk3">honk3</a>.<p>You should be able to run it yourself as well, of course, but there’s likely to be some churn until everything stabilizes.]]></description>
      <category>activitypub</category>
      <category>project</category>
      <link>https://flak.tedunangst.com/post/enterprise-social</link>
      <pubDate>Tue, 02 Jul 2024 16:41:31 UTC</pubDate>
      <guid isPermaLink="true">https://flak.tedunangst.com/post/enterprise-social</guid>
    </item>
    <item>
      <title>sometimes the commit is misattributed</title>
      <description><![CDATA[<p>A response of sorts to commit robbery.<p>I’ve been on both sides of commit misattribution. Sometimes my commit gets sniped. Sometimes I’m the one doing the sniping. It’s very rarely intentional.<p>In a project like OpenBSD, we’d have three Todds and four Jasons, which led to frequent confusion. Forgetting exactly who contributed what would happen occasionally. Emails get forwarded around. And I think every new OpenBSD developer goes through the experience of having half their commits sniped for the first month because other developers think you’re submitting a patch, not requesting review.<p>I’d guess 1% of commits are misattributed in some way. There’s an acknowledgement, but it’s incomplete. Or it’s omitted. Or it credits somebody else entirely. I think that’s not bad overall, though it does mean 1% of first time contributors have a suboptimal experience. It sucks to be the statistic.<p>Could the 1% be improved? Sure, just require a few more TPS reports before commits are permitted. If the solution is that we simply need to ask the maintainers to <i>care</i> more, are we sure they don’t care? There’s already enough people burning out and dropping out of open source work.<p>I think Ariel’s story could have been framed better, with a rather less villainous counterparty. I almost didn’t read it, because I don’t care about commit drama, but the story of the debugging was really interesting. I’m glad I read that! But hey, your blog, your story. That said, I don’t think it’s possible to generalize from one event to sweeping conclusions like this is why people don’t contribute to open source. This is, maybe, why 1% of people don’t contribute to open source.]]></description>
      <category>thoughts</category>
      <link>https://flak.tedunangst.com/post/sometimes-the-commit-is-misattributed</link>
      <pubDate>Tue, 14 May 2024 16:50:14 UTC</pubDate>
      <guid isPermaLink="true">https://flak.tedunangst.com/post/sometimes-the-commit-is-misattributed</guid>
    </item>
    <item>
      <title>the chilling effect is coming from inside the house</title>
      <description><![CDATA[<p>Big Stomper is out to get you. Better watch what you say, or you’ll get stomped.<p>Of course, they won’t admit to stomping you. They’ll even deny it. Make it look like an accident or natural causes, an unfortunate rockslide. But you’ll be stomped just the same. All for speaking out about their misdeeds.<p>Not everyone believes Big Stomper is even responsible, but I hang out on the Stomp Watch forum, where we catalog and discuss the evil things Big Stomper is up to. So we know that when something bad happens, Big Stomper is to blame. Sometimes we debate if the stomping is carried out in house, or contracted out, but we are all agreed that the murky lack of evidence is a clear sign that professionals are involved. These are not amateur stompers.<p>Because I know what Big Stomper is capable of, it would be irresponsible not to warn you what happens to anyone who reveals their secrets. Everyone at Stomp Watch would love to discuss your revelations, but you need to know that you will definitely get stomped. Big Stomper does this to dissuade future leakers.<p>Some people (there’s always that “someone” on the internet, right?) will tell that it’s safe to come forward, these are just rumors and wild speculation. Well, they’re not the ones risking their lives, are they? Anyone inside Big Stomper who feels obligated to disclose the truth should come check out Stomp Watch first to know the risks.]]></description>
      <category>rants</category>
      <link>https://flak.tedunangst.com/post/the-chilling-effect-is-coming-from-inside-the-house</link>
      <pubDate>Thu, 09 May 2024 22:11:26 UTC</pubDate>
      <guid isPermaLink="true">https://flak.tedunangst.com/post/the-chilling-effect-is-coming-from-inside-the-house</guid>
    </item>
  </channel>
</rss>
