Do the browse and download tutorial first if you do not already have the app and an in-app wallet on Arbitrum One. Rewards, profile edits, and uploads all use that same wallet. The web catalog at app.torrentech.org cannot pin, free-download, or upload. The shorter page is Pin & earn. Reward amounts are also on tokenomics.
PinRewards on Arbitrum One is unpaused. There is no claim button. A registered verifier samples during the period and the settling report mints after the period closes.
| Pinner / uploader (this guide) | |
|---|---|
| Everything in the browse and download tutorial | Yes, on the desktop app |
| Upload a new release (bytes on your node until it is reviewed) | Yes. upload in the top nav, after sign-in |
| Keep your own durable copy | Yes. Download and Pin, and the pin made when you unlock a format |
| Earn TTT for pinning | Yes, when your profile’s Peer ID is the node that served the sample, the release is published (moderator-approved uploads count), and a sample in that period passed |
1. The bundled Kubo node
Run the desktop app. You do not install IPFS Desktop for normal use. The footer IPFS / This machine cell shows a peer count (1 peer, 12 peers, …) when the sidecar is up, or down when it is not. Wait for peers before you trust a local pin.
| Production app | Torrentech Test | |
|---|---|---|
| Library | ~/Torrentech (change from the IPFS This machine cell) | ~/Torrentech-test |
| Kubo API | 127.0.0.1:15001 (loopback only; stock Kubo is :5001) | 127.0.0.1:25201 |
| Repo | <library>/.torrentech-ipfs | same layout under the test library |
Public pin rewards are checked against the production mesh. Use the production app for that. Test builds talk to the test stack.
Windows bundles Kubo and can pin. It does not bundle a Ceramic sidecar; catalog reads stay on the Torrentech replica. Linux and macOS also start a local Ceramic replica. Writes (uploads, profile, comments, votes) still go to hosted Ceramic. See footer status in the browse and download tutorial.
The library path is shown under the IPFS This machine peers, with change. change opens Choose library folder and moves the sidecar repo with it. The onboarding line is: “Albums pinned from this folder must stay here.”
At start the sidecar joins the public IPFS mesh (AutoConf, mDNS on, leftover private-swarm filters removed). Extra bootstrap:
/ip4/95.217.135.193/tcp/4002/p2p/12D3KooWSrKeJ8jinMaDzBJDKPycKU99AiVvth7bNXkkY2oSCwPhipfs.torrentech.org is the HTTP gateway, not this swarm address.
Optional check against the local API (http://127.0.0.1:15001/api/v0 on the production app):
ipfs id
ipfs pin ls --type=recursive
ipfs pin ls --names
ipfs swarm peers
ipfs filestore ls
ipfs filestore verifyPoint ipfs at that API (Kubo’s --api flag) if another daemon is also installed. Homebrew Kubo on :5001 is not the app’s node. filestore ls and filestore verify are the check for --nocopy uploads: each pointer should still resolve to a file under the library.
Library and filestore uploads
Choose album folder on the upload form opens the operating-system folder dialog. On Linux that dialog is required: the in-app file control cannot pick a whole album. The dialog opens at the library.
User and moderator uploads run ipfs add -r --nocopy on a folder under the library. One copy of the files stays on disk; the repo holds filestore pointers. A folder picked outside the library raises Move into the library? The app copies or moves it in. A cross-device copy keeps the library folder even when the original cannot be deleted.
Those files have to remain at that path. Moving or deleting the album makes the pin hollow: a later leaf fetch fails, and that album is not counted as a pass. There is no supported ipfs repo gc on this sidecar. Garbage collection drops filestore pins.
Download and Pin is different. It pins the CID into the repo (blocks live in the node) and also writes a playable folder under a parent you choose. Deleting that saved folder does not unpin the repo copy. Unpinning, or a garbage collection aimed at this repo, does.
Admin catalog ingest does not --nocopy onto the admin sidecar and does not move the folder into the library. It streams the folder to the catalog seeds. That button is Pin to catalog, described under upload.
2. Tell the platform which node is yours
Verifiers map a providing Peer ID to the wallet that controls the profile with that Peer ID. A self-typed wallet address is not the lookup. An empty or stale Peer ID earns nothing, however much is pinned.
Automatic. For a normal user or a moderator, when the profile’s Peer ID field is empty, the app publishes the sidecar’s id on profile refresh and when Kubo starts. It fills an empty field only. It does not overwrite a Peer ID that is already saved. Admins are never auto-filled, so a staff session cannot publish the catalog node by accident.
Profile → IPFS Peer ID (open Profile in the session bar):
| What you see | What to do |
|---|---|
| The id, and “Matches the IPFS node running on this device. Needed for pin reward verification.” | Leave it. Verifiers can credit this node |
| “This node reports this Peer ID…” and Use this node | The field is empty and auto-publish has not landed. Press the button. Success: “Saved. Verifiers can credit this node from the next period.” |
| “Your profile points at a different node…” and Point rewards at this node | The saved id is another machine. Pins on this machine earn nothing until you point the profile here |
| “Start IPFS (status in the app) so this device can publish its peer ID.” | The footer IPFS cell is down. Relaunch, then reopen Profile |
| “Not detected” | Same: sidecar not up, so there is no local id to save |
There is no paste field. The button reads the node that is actually running. ipfs id against 127.0.0.1:15001 should print the same Peer ID.
Two profiles that publish the same Peer ID earn nothing for either profile. The catalog node’s Peer ID is reserved. Publishing it does not credit your wallet. Do not copy an operator Peer ID onto your profile.
3. Pin a release you did not upload
On a published format, after the wallet has access:
- Pay
<cost>TTT or Free download (desktop). When the local node is up, that unlock also pins the CID. The pin name isTorrentech download: <artist> - <album> [<format>]. The row then offers the download buttons from the browse and download tutorial. - Download and Pin (shown only when the daemon is reachable; the label is Saving… while it runs). You pick a parent folder. The app pins the CID as
tT release: <artist> - <album> [<format>], then writes a child folder:
Artist - Album [year] [FORMAT]Empty year or format is omitted. Slashes anywhere in the artist, album, or format become -, so FLAC / 16-bit is [FLAC - 16-bit]. A retry skips files already in that folder with the same byte size, so an interrupted save can continue. The saved files are the album you can play. The pin in the repo is what has to stay for a later sample.
Open in IPFS, Open using IPFS gateway, and Gateway .tar do not replace the pin.
Keep the app running, with that content still pinned, across the samples in how a pin becomes TTT. Quitting the app stops the sidecar. A pin that is present only while the verifier is not looking is a miss for that sample.
Check names:
ipfs pin ls --type=recursive
ipfs pin ls --names | grep -E "tT release:|Torrentech download:"4. Upload a release
upload is in the top nav after you sign in on the desktop app. The form says “Please connect your wallet to upload releases.” until that session exists.
| Field | Required | What it is |
|---|---|---|
| Weblink | No | Placeholder: “Discogs, Bandcamp, MusicBrainz, Apple Music, or Beatport URL”. fill pulls artist, album, date, tags, tracklist, and cover when the page can be read. Leaving the URL clears fields that fill wrote |
| Artist | Yes | |
| Album Name | Yes | |
| Label | No | |
| Release Year, Month, Day | No | Year is bounded by the form. Month 1–12. Day 1–31 |
| Tags | No | Genre, Format, Source, Descriptive. Format and Source allow one tag each |
| Tracklist | No | |
| Cover Art (Image) | No | Image file. A weblink fill may set this and show a short notice |
| Content File/Folder | Yes | Choose album folder. The hint: “Opens at the library folder. Albums outside it can be moved in; pinned albums must stay there.” After a pick, the form shows file count, audio count, size, and the directory name |
| File format | Yes | The allowlist from Administration (for example FLAC / 16-bit, FLAC / 24-bit, MP3 / 320k CBR). Generic FLAC and bare MP3 are retired and are not in the menu. If the menu is empty: “No allowed formats configured. Ask an administrator to add formats in Administration.” |
| Remark | No | Maximum 256 characters |
Submit release runs the add, then the Ceramic write. The button shows the current phase while it is busy. On success: “Release uploaded successfully! CID: …”. If a similar artist and album already exist, the form names them and tells you to check for typos; you can still submit when that is intentional.
What the node stores:
- The album is added with
--nocopyfrom the library folder. Keep that folder in place. - The recursive pin is named
tT release: <label> [<format>] - [1/<blocks>], where<blocks>is the number of chunk refs. A published file without its chunk manifest is invisible to pin verification, so a finished upload always has one. - Cover, when present, is pinned as
torrentech cover.
The new release is not public until a moderator approves it. my pending uploads lists three groups:
- Pending — waiting for moderation. Open / Edit.
- Approved — status sync pending — a moderator approved it and the public status has not caught up. Open Details / Retry.
- Rejected.
Until it is published (or approved), it is not in the reward sample set. After approval it is eligible like any other published format, still only while your node can serve it and your Peer ID matches.
Admins
On a user or moderator format that is not already a catalog copy, desktop admins see Pin to catalog. That lands the CID on the catalog seeds with --nocopy and the same Artist - Album [year] [FORMAT] directory name. The button’s own download action reads Download to folder and does not pin that CID onto the catalog node. User and moderator streams can then be copied onto a catalog Ceramic stream.
Administration → Pin Rewards is admin-only and read-only. It lists closed periods for the connected wallet (paid pins and TTT, or reports so far). A normal pinner does not use that screen. The mint arrives on the profile wallet with no claim transaction.
5. How a pin becomes TTT
| Rule | Live behavior |
|---|---|
| Reward | 5 TTT per pin that passed. A failed check is left out of the count. The mint is count × 5 TTT |
| Period | 1 day on Arbitrum One (86400 seconds). The period length is fixed on the deployed contract |
| Samples | 06:00, 12:00, and 18:00 UTC. Later runs in the same period add albums the earlier runs did not already record. A pass is a fetch of one leaf from the peer named on your profile. Finding the peer in a provider list is not the pass; the checker dials that peer |
| Payout | After the period closes, a registered verifier reports one count per wallet. There is no claim button. The report that settles the wallet mints to that wallet. A missed day can still settle on a later run (a few closed periods back) |
| What counts | Published releases, including moderator-approved uploads. Equal chance per pin in the scan. Creating or approving a release does not pay by itself |
| Your cap | Each community wallet can be credited up to 1,000 pins in a period. All community wallets together share a larger pool (default 2,000 pins a period). The 1,000 figure is the one that applies to a single pinner |
| Who is paid | The wallet that controls the profile for the Peer ID that served the leaf |
Keep the app and its Kubo sidecar running, and keep the album pinned, across at least one sample in the period you care about. A miss is omitted from that period’s paid count. The next period starts clean.
Only release pins are rewarded. Avatar pins, unnamed experiments, and a catalog you are not actually serving do not add to the count.
6. GUIBo (optional)
GUIBo is a third-party Qt desktop app for people who already run Kubo. It talks to Kubo’s HTTP RPC and can list pins, add files, work with IPNS, inspect swarm and repo stats, and export UnixFS files. It does not replace the Kubo daemon, and it does not replace Torrentech. The Torrentech app already pins, names those pins, and publishes your Peer ID. You do not need GUIBo to earn TTT.
If you want that extra window on the same node the app started, point GUIBo’s RPC URL at:
http://127.0.0.1:15001That is the production sidecar API. It is loopback only. Torrentech Test uses http://127.0.0.1:25201 instead. The Peer ID GUIBo shows should match Profile → IPFS Peer ID.
Builds on that site at the time of writing are 1.1.4 (Linux AppImage, .deb, and .rpm for amd64 and arm64; macOS .dmg for amd64 and arm64; Windows setup and zip for amd64 and arm64). Check the site for a newer build.
Without a license, GUIBo stays in trial mode: the pin list shows at most three rows (the status line still has the full count), Add to IPFS accepts files only and at most three files per add, and auto-refresh stays off. A lifetime license is US $5, paid in DAI, USDC, or USDT on Ethereum mainnet (not Arbitrum), from the Activation dialog inside GUIBo. That payment is GUIBo’s, not a Torrentech fee, and it does not interact with TTT.
Use GUIBo to look: pin list, pin-type filter, copy a CID, Peer ID, swarm, repo stats. Leave unpin and repository garbage collection unused against the Torrentech sidecar. Either one drops the copies the verifier fetches, and garbage collection is especially destructive for --nocopy uploads whose only bytes are the library files plus filestore pointers. Torrentech has no supported ipfs repo gc on this repo.
GUIBo’s public-gateway “open” action uses https://ipfs.io/ipfs/…. Torrentech album bytes are token-gated, so that public URL is the wrong way to fetch a catalog release. Use the app’s Open using IPFS gateway after you have unlocked the format, or read the files Download and Pin already wrote.
7. Larger nodes and other people’s Kubo
The desktop sidecar is the supported pinner. A node that serves a lot of data wants Pebble or Badger on SSD, reprovider strategy roots, and connection limits. Flatfs plus reprovide-all does not scale at that size. That tuning, a standalone Kubo, and a 24/7 VPS seeder are operator setups, not this desktop path. On a standalone node, filestore has to be enabled and albums have to stay under the directory that contains the IPFS repo.
If you pin with a node the app did not start, Point rewards at this node only works for the sidecar the desktop app can see. A remote daemon still has to be the Peer ID saved on the profile, and that profile has to be written from a session that can publish it.
Troubleshooting
- “Local IPFS node not reachable — downloads won't be pinned.” Sidecar Kubo is down. Gateway
.tar/.zipstill work. Quit from the tray and relaunch. The IPFS This machine cell should show peers. - “already stored in the blockstore; filestore pin is not possible for this album.” This sidecar already has a normal (copied) pin of that album, so
--nocopycannot take it. Re-upload under a new folder name, or wait. There is no sidecarrepo gcto clear the old blocks. - Uploaded album missing, or the pin looks hollow. The
--nocopyfiles left the library. Put the same folder back under the library path, or upload again. A leaf the peer cannot serve is not a pass. - Profile Peer ID does not match this machine. Point rewards at this node. Until you do, samples answered by this Kubo are not yours. If the field is empty, Use this node after the IPFS cell shows peers.
- Pinned, and still no TTT. Check all of these: the profile Peer ID is the node that would serve the leaf; the release is published (pending uploads are not in the sample); a sample in a closed period passed (samples at 06:00, 12:00, and 18:00 UTC; mint follows the close); you are under the 1,000 pin cap for that period; the Peer ID is not the catalog node and not a duplicate of someone else’s profile. The mint goes to the profile’s controller wallet. Administration → Pin Rewards is only visible to admins.
- Download and Pin saved files, then the app was quit. The repo pin survives the next launch only if you did not unpin it and did not garbage-collect the repo. The sidecar has to be running at sample time for the checker to dial you.
- Contact from moderators about an upload: they use Blockscan Chat, or Matrix and email if you set those on Profile. Details are in Getting help.