rtClient.upload and rtClient.arweave
SDK methods for putting a file into the protocol and for reading what has been archived permanently.
Two services, one story. rtClient.upload puts a file in; rtClient.arweave reads what the
protocol has archived permanently. See Storage for the provider-neutral
model and what "permanent" is guaranteeing.
rtClient.upload
rtClient.upload.uploadFile(file, metadata?, options?)
Uploads a File and returns ApiResponse<UploadResponse>. metadata is a flat
Record<string, string>. options.onProgress receives a 0-100 number, which is what a real
upload UI needs - files here are large enough that a spinner is not enough.
const res = await rtClient.upload.uploadFile(file, { kind: "artwork" }, {
onProgress: (p) => setProgress(p),
});rtClient.upload.uploadUserAvatar(file, userId, options?)
The avatar path, same progress option.
Identity is edited in one place. rt-profile owns name, bio, avatar and social links; a client app renders them and links out to rt-profile to change them. A client app calling this is the split going wrong.
rtClient.arweave
A read surface, and only a read surface. The protocol holds no Arweave key - a permanent copy
is written by the edition owner, from their own session, with their own key. The methods that do
that writing live elsewhere: rtClient.users.getStorage for what a key can hold, and
rtClient.productInstances.planSaveAs / postSaveAsReceipts / postSaveAsManifest for the three
legs of a Save As. See Storage.
rtClient.arweave.listForUser(stxAddress, params?)
What this address has archived. Returns ApiResponse<ArweaveListForUserResponse>.
rtClient.arweave.getTxStatus(txId)
Status of one archival transaction. Returns ApiResponse<ArweaveTxStatusResponse>.
Archival is not instant and gateway propagation can take minutes to an hour - a status that is not yet final is the normal case shortly after a Save As, not an error to surface as one.