<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Releases on BitSpeed.org</title>
    <link>https://bitspeed.org/tags/releases/</link>
    <description>Recent content in Releases on BitSpeed.org</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://bitspeed.org/tags/releases/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>BitSpeed Inspect Explains HTTP Transfers and Compares Saved Runs</title>
      <link>https://bitspeed.org/bitspeed-inspect-explains-http-transfers-and-compares-saved-runs/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bitspeed.org/bitspeed-inspect-explains-http-transfers-and-compares-saved-runs/</guid>
      <description>&lt;p&gt;A slow request gives you a duration. The next question is where that duration came from, and whether the same interval changed after you adjusted something. BitSpeed Inspect records the client events behind one HTTP transfer and turns them into an explanation you can revisit.&lt;/p&gt;&#xA;&lt;p&gt;Inspect 0.1.1 is available as an independent Go command. It saves JSON, explains one recording and compares two sets of samples. Transfer has its own release and delivery checks, and neither command depends on the other.&lt;/p&gt;</description>
    </item>
    <item>
      <title>BitSpeed Transfer Resumes Interrupted File Transfers From Verified Chunks</title>
      <link>https://bitspeed.org/bitspeed-transfer-resumes-interrupted-file-transfers-from-verified-chunks/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bitspeed.org/bitspeed-transfer-resumes-interrupted-file-transfers-from-verified-chunks/</guid>
      <description>&lt;p&gt;An interrupted transfer should not make you guess which bytes arrived. BitSpeed Transfer 0.1.0 starts with a saved snapshot, splits it into hashed chunks and asks the receiver to substantiate its progress after restart. Repeat the send command with the same snapshot and ID, and it sends the chunks still missing. The original source can stay out of the recovery path.&lt;/p&gt;&#xA;&lt;p&gt;Completion has a separate gate. The receiver assembles the file, checks its full digest and publishes a fixed destination without replacing an unrelated file. A retained witness and stable receipt let the next request verify that same output after a lost final response. The sender checks the receipt against its manifest and saves it locally before saying transferred true. A staging result alone is not enough.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
