Show HN: PikaTorrent, a modern, multi-platform, open source BitTorrent app (pikatorrent.com)
PikaTorrent tries to offer a modern and easy UI. It is available on desktop (Linux & Windows for now), mobile (Android for now), as CLI as an npm package, and even on the web (as a frontend for remote control).
Thanks to WebRTC, one can link the mobile or web app with the desktop or CLI app. This way, it's possible to remotely manage torrents securely and without any complicated setup.
From a technical point of view, the app is using Expo and Tamagui to target the web, desktop, and mobile (native), meanwhile libtransmission is used as the torrent engine. So we should expect the same level of performance as the Transmission client.
PikaTorrent is open source, and I just released v0.3.0 to let potential users try it out and contribute to the bug/features list on GitHub: https://github.com/G-Ray/pikatorrent. Thank you for your feedback.
47 comments
[ 3.4 ms ] story [ 109 ms ] threadThe web UI does the job, no complaints.
Hosting multiple services behind one ip:443 and having a valid LE certificate is surely a nice thing. You can even add a simple URI knocking if you wish.
Putting nginx in front with http basic auth would prevent all of them.
I understand that Hacker News users are generally power users. If qbittorrent fulfills your needs and you have the skills to setup and secure a webserver, there is no need to switch to another client. Additionally, it's worth noting that PikaTorrent may not implement all the features of qbittorrent anyway.
Transmission's main maintainer published this in 2010: https://gist.github.com/ckerr/89882362c65b819614051935364b9e.... This comparison was done between clients, so there is overhead involved due to the GUI, but still.
https://github.com/transmission-remote-gui/transgui
What would be wrong with it or anything similar? Every information is just there, no need to swipe left and right to read information that has been either hidden elsewhere or, worse, taken away. The same applies to many "old" clients such as QBittorrent and others.
I understand that design is important, but it should never ever win over functionality.
When I mentioned the "old" interface, what I meant was that it may not be as attractive to newcomers. I understand that a UI can be old but perfectly functional.
Not only there is too much whitespace so you can't see more than two torrents, but..
Why there is a search bar? Pointed to Google?[0]
Why anyone need a gigantic Start/Pause and Remove buttons on a separate line?
Why the Remove button is so easily accessible, especially on a touch enabled device?
Why is there Status status if there is already a button?
Why there is a file counter? Did anyone care about how many files in a particular torrent?
Why there is no way see the actual torrent name on a touch device in the portrait mode?
Why anyone would need to see ETA and Download rate and Progress for a seeding torrent?
[0] bonus points if you are accessing it in a web browser
I strive to maintain parity between the mobile and desktop UIs, and I understand that some tweaks are needed to reduce the used space.
The file counter is a button that displays the downloaded files. In the near future, users will be able to directly open files from this view. For example, this will enable playing media files directly from PikaTorrent.
The displayed information and ordering can be customized from the settings. If you prefer not to see ETA or other information. The default settings might changed based on feedback received, such as yours.
No, I don't care if you can configure the search bar, I'm asking why does it even exists. I never 'searched for torrents from the BT app itself', it's pointless. It's just some known tracker already and if something isn't there then I would be in the browser already, why do I need to switch to some app to open the browser with my search again?
> and I understand that vissa tweaks are needed to reduce the used space.
You need to throw your cool, responsive and 'parity' UI to the trash and start again. With the mobile UI as a primary target and expanding on the landscape and deskto p modes
> The file counter is a button that displays the downloaded files
REALLY?
Okay, I would ask you again: who ever bothered with the count of already downloaded files?
If there is only 1 file in the torrent then this counter is useless.
If there are some files but you do really need only one (eg Debian/Centos/Rocky distros) then this counter is useless.
If there are many files but they are all needed at once then this counter is useless.
The answer for this question is what no one ever bothered with such counter. It's the reason you don't see this counter in the stats in any other BT client.
> enable playing media files directly from PikaTorrent
... don't forget to add a juice extractor to your car, just in case you would be going 120MPH and suddenly realize you need some fresh orange juice.
But really, a BT app is a BT app, not a food processor with built-in grill and vacuum cleaner. Nobody 'plays' media files from a BT app, that's what media players are for.
> The displayed information and ordering can be customized from the settings
You should have a compact, useful UI from the start, not after having a two session tinkering with the settings. Also it doesn't help if you still forced for all those stupid info and buttons.
Go up to my previous comment and re-read it.
Also you should really think about what are trying to do.
Because if someone can't handle making a web server and tls cert to have a remote access (which isn't even needed because all BT clients provide their own http server) then it's surely not the person who would install your client through npm.
> Vote to ban this account
You do not understand. But you will.
This has worked for everyone so far, it cant be that hard.
Old UI doesnt mean bad UI. It means time tested, reliable, proven. Bad UI is UI which isnt being used because its so bad.
This still has a cognitive load though.
When dealing with hundreds of torrents, I believe filtering options and a simple text filter would be more useful in quickly finding specific torrents. What are your thoughts on this?
That being said, based on the feedback, it seems necessary to reduce some vertical space in these cards.
More advanced users are very unlikely to use something with such UI. I can't imagine that it will be fun to use while having 10 torrents, let alone 250+.
Even Fragments[1], the GNOME Circle app for BitTorrent that targets casuals can fit more downloads in a single view.
And what's the point of the search bar? All it does is open a new tab and search "torrent <keyword>" in either Google or DDG. I can do it myself. It's neither helping newbies nor advanced users.
Also the 1.7M package-lock.json[2] scares me, but so do most JavaScript projects. Do we really need that many JS libraries for a UI for a BitTorrent client?
In comparison, Transmission's web UI has a package-lock.json that uses 354K[3].
1: https://apps.gnome.org/en-GB/app/de.haeckerfelix.Fragments/
2: https://github.com/G-Ray/pikatorrent/blob/main/package-lock....
3: https://github.com/transmission/transmission/blob/main/web/p...
As an advanced user myself, remote control is important to me, but I also want to introduce more people to BitTorrent through a simple UI. Based on the comments, it seems I have missed the target for advanced users with these large cards, this is something I would like to improve.
What would you suggest? Should I offer two view modes, one with cards and one with a list? I could find a way to reduce the vertical height of the cards anyway.
In the near future, I plan to utilize the horizontal space to add filter and label management options, allowing users to quickly find specific torrents. I think displaying hundreds of torrents simultaneously isn't practical as I can't process them all. Instead, I believe a search bar and filters would greatly enhance the user experience. It seems people here would prefer a table view instead, like qbittorrent, what are your thoughts on this?
The search bar allows you to quickly search using the selected search engine. Google is just an example preconfigured in the settings, but you can configure any search engine of your choice. For example, you can add archive.org with the URL "https://archive.org/search?query=". While I may consider integrating a search feature with plugins in the future, I currently find the existing search bar to be a simple & time-saving shortcut for finding torrents online.
Regarding the package-lock.json, I understand your point. However, please keep in mind that PikaTorrent is a monorepo. It includes the website, app (web & mobile), desktop (electron), and CLI. There are numerous development dependencies that are not bundled into the final app.
I'm personally not a fan of the card view in BitTorrent clients, but I'm not necessarily against having one, but it has to be more compact than what it is now. If you want to attract more advanced users, having a list view would be pretty important if you ask me. Having both could be an option.
But keep in mind that you don't have to satisfy everyone, because that's not even possible.
> In the near future, I plan to utilize the horizontal space to add filter and label management options, allowing users to quickly find specific torrents. I think displaying hundreds of torrents simultaneously isn't practical as I can't process them all. Instead, I believe a search bar and filters would greatly enhance the user experience. It seems people here would prefer a table view instead, like qbittorrent, what are your thoughts on this?
I personally use Transmission and the default view is compact enough for me. Search for the torrents loaded into the client is a must for me, but I personally don't really care about labels. But that's just me.
> Regarding the package-lock.json, I understand your point. However, please keep in mind that PikaTorrent is a monorepo. It includes the website, app (web & mobile), desktop (electron), and CLI. There are numerous development dependencies that are not bundled into the final app.
That's fair I guess… but homepage alone seems to have 1202 dependencies (180 of them need funding and one is deprecated), seems a lot for 2 static pages. I'm not the one that will have to maintain it, but at some point something will break… Also the performance of the homepage seems to impacted by the frameworks used[1].
1: https://pagespeed.web.dev/analysis/https-www-pikatorrent-com...
[1] https://news.ycombinator.com/item?id=29553767
However, in the context of a terminal like Tabby or Hyper, it may make less sense to choose web technologies over cross-platform native libraries. I suppose the goal here was to create an easily "hackable" terminal experience.
What you've done actually makes it harder to use, because in order to configure any of transmission's settings (ports, connection/torrent connection limits, bandwith limits, etc) the user needs to dig around to find the transmission config folder and then manually edit JSON with a text editor - because your client doesn't expose any of transmissions numerous settings [1] to the user except for choosing the download folder.
I'm not sure why anyone would want to use this instead of Flood [2] or even old Transmission Web Control [3]
1: https://github.com/transmission/transmission/blob/main/docs/...
1: https://github.com/jesec/flood
2: https://github.com/ronggang/transmission-web-control
I preferred to bundle libtransmission to offer a plug'n play experience across all platforms.
Regarding all the criticism here, I believe PikaTorrent should primarily focus on new or average torrent users. Advanced users might either modify the settings file manually for now (though guessing the path is not ideal), or perhaps PikaTorrent should expose a textarea to edit transmission settings (though this approach might be risky for average users).
In the meantime, I plan to expose a lot more Transmission settings in the UI. Even for me, PikaTorrent is not mature enough to fulfill all my needs. However, with more features to come and potential feature requests from users on GitHub, it might become a suitable BitTorrent client for advanced users and server usages.
Thank you for the few valuable feedback. I will continue to iterate and improve pikatorrent. Please don't hesitate to share your thoughts and feature requests on GitHub/Discord.