youndie@kotlin.website:~/src$ cat s3kn/README.md

s3kn

kmp: linux + apple + jvm · ktor · sigv4 · s3
S3 where the AWS SDK does not go — Linux, macOS and iOS as well as the JVM. SigV4 checked against all 34 official vectors plus twenty more generated from the reference implementation, presigned URLs that work even on targets with no HTTP engine, and every operation run against a real server on two platforms.
github/s3knread the write-upall libraries

Why it exists

The AWS SDK for Kotlin publishes JVM artefacts only. On Kotlin/Native the two remaining options are binding aws-c-s3 through cinterop — five C libraries and their build, on every target — or writing the protocol out. This is the second one: a signature and seven HTTP requests.

What you get

  • Signature Version 4, header-based and in the query string, verified against all 34 official AWS test vectors, including the four other SDKs skip.
  • S3's own signing rule, where the path is signed verbatim — no dot segments removed, no second round of encoding. Every other AWS service does the opposite.
  • Presigned URLs for reading and writing, to the seven-day ceiling. Presigning sends nothing, so it works on every KMP target, including those with no HTTP engine at all.
  • put, get, delete, head, streamed both ways, so a five-gigabyte object is never held whole.
  • Listing as a Flow of pages with encoding-type=url always on, because an object key may hold characters XML 1.0 cannot represent.
  • Multipart upload, bounded memory, and an abort on every path that can fail — parts nobody completes are billed until somebody notices.

Install

repositories {
    mavenCentral()
    maven("https://reposilite.kotlin.website/snapshots")
}

dependencies {
    implementation("io.github.youndie:s3-client:0.1.0-SNAPSHOT")
    // The engine is yours, and which one exists depends on the target.
    implementation("io.ktor:ktor-client-curl:3.5.2")   // Linux, Windows, macOS
    implementation("io.ktor:ktor-client-darwin:3.5.2") // macOS, and the only choice on iOS
}

s3-sigv4 can be taken on its own if all you need is signing or presigning — it has no HTTP dependency at all.

Platform support, stated honestly

linuxX64 is what this is built for and the only target it is claimed to work on: the whole suite runs there, live tests included. jvm runs the same code and the same live tests in CI. macosArm64 has had the full suite run against a real server by hand. iOS compiles and publishes; a device test has never been run.

"It compiles" and "it moved bytes to a real bucket" are different statements, and only one of them belongs in a support table.

more
tracybooblikpetichmetrikkatchermongkn