Document new session handling and announce the 0.2.0 release of the r…

…unner

content/2.runners/1.about.md

@@ -52,7 +52,24 @@ To see all options when configuring the runner, you can run the following comman
 
 You can remove your runners from your profile. Once removed from your profile page, the runner will not be able to connect to the back-end anymore. 
 
-On your own machine, the runner registration information is stored in the `.runner` file. If you remove this file, the runner will still exist on the server, but you will have no way to connect to it anymore.
+On your own machine, the runner registration information is stored in the `.runner` file. If you remove this file, the runner will still exist on the server, but you will not have a way to connect to the server anymore.
+
+### Session
+
+The runner uses two types of tokens for authentication:
+1. **Runner Token**
+
+    The runner token is used for routine operations such as acquiring jobs, completing jobs, and general communication. This token is designed to be long-lived and is generated as a globally unique UUID v4, making it highly secure and nearly impossible to guess.
+
+    To enhance security, the runner token has a lifetime of 30 days. A session refresh mechanism allows the token to be renewed within this period. If the token expires without being refreshed, the runner will no longer function, requiring reconfiguration.
+
+2. **Worker Token**
+
+    The worker token is specific to job-related tasks, such as resolving jobs, updating timelines, and uploading logs and assets. This token is short-lived, with a fixed 4-hour lifetime and no refresh mechanism.
+
+    The 4-hour limit is intentional for the following reasons:
+    - **Workflow Integrity**: Jobs running longer than 4 hours may indicate a design issue. Breaking large tasks into smaller, interdependent jobs ensures better resource management. Expired tokens free up runner capacity for other jobs.
+    - **Security**: The worker token is only communicated to the runner when acquiring a job and is not stored on the file system, minimizing exposure even if the machine is compromised.
 
 ### Running the runner
 

content/999.announcements/1.all.md

@@ -4,6 +4,24 @@ title: "All announcements"
 
 # Announcements
 
+## Runner version 0.2.0 is released
+
+New runner has been [released](https://github.com/bountyhub-org/runner/releases/tag/0.2.0) 🎉! 
+
+This release contains major refactor on client to be able to refresh the session. The session token is switched from JWT to random UUID v4. There are two session tokens used by the runner:
+1. **Runner session token** - Used by the runner to request jobs and keep it alive.
+2. **Worker session token** - Used by the runner worker to resolve the job and execute it.
+
+Since there are different use-cases for them, each session token have a different lifetime.
+
+Runner session token lasts for 30 days. If your runner is kept offline for more than 30 days, you will have to
+re-register the runner.
+
+Worker session token lasts for 4 hours. This should be enough time for the worker to finish the job. If job gets
+stuck, session token would expire which would cancel the job and release the runner to pick up other jobs in case
+there is a bug in a workflow.
+
+
 ## Billing is almost done
 
 I'm currently opening a company based in US. Until the bank account is opened, I cannot meaningfully implement