I updated my publicly accessible ANTTP with the new docker image. It seems moderately faster than it was before.
Hey my man! Does your streaming system stop people from directly downloading and copying the streamed content?
No, not at all - to the user, it just feels faster. Everything else looks the same from the client, really.
I’m asking if your streaming system can prevent easy copying. Can it defeat screen capturing.
No, it isn’t designed to prevent copying. The client receives the same data.
From the client’s perspective, the data just arrives in smaller pieces (sooner), rather than all at once (later).
Note that it implements standard HTTP protocol features to achieve this. The solution isn’t proprietary and is intended to be open.
I’ve (finally) published AntTP to crates.io here: crates.io: Rust Package Registry
So, you can now do cargo install anttp
to build and install the AntTP.
If you’re a developer, you should also be able to pull in anttp
as a dependency now too. Be warned, I’ve done little/no preparation as to what to expose in this usage though. I plan to make it more ‘library friendly’ in the future though.
Is there any way to pass --max-fee-per-gas 15000000
to anttp?
Im short on ETH-ARB and BitMart is not recognising me as human today. Need to go to the bank tomorrow and get it done manually… sigh
Hmm, not afaik! It will just be using the autonomi library defaults, I believe. I’m not sure if that can be sent through a build parameter either, as I’ve not really played with that option yet.
Obviously, that only impacts uploads though.
Yes Im kinda wanting to publish
Pro-tip 1: To start brave browser with the proxy set…
- Install brave browser
- Start
anttp
in one terminal window. - Run brave from another terminal window, e.g.
brave --proxy-server="127.0.0.1:8080"
Pro-tip 2: To start brave browser with the proxy set and a URL opened…
- Run brave with a URL argument, e.g.
With Traktion’s IMIM blog:
brave --proxy-server="127.0.0.1:8080" http://62003e683b5a792f425a75c5d7d99d06e80f7047be8de8176b7d295e510b3b4c/blog/cec7a9eb2c644b9a5de58bbcdf2e893db9f0b2acd7fc563fc849e19d1f6bd872
Or some BegBlag:
brave --proxy-server="127.0.0.1:8080" http://a0f6fa2b08e868060fe6e57018e3f73294821feaf3fdcf9cd636ac3d11e7e2ac/BegBlag.mp3
The above is for Linux, but the same argument should apply for windows (although the brave
command may be different).
A new minor version with some refactoring on the streaming side and minor fixes.
In bigger news, I’ve had to change the license, as it was incompatible with the Autonomi Client Library. In short, the library is GPL 3.0, which means AntTP must be at least as copy left.
Web apps which are built on AntTP remain unchanged licensing wise, as the license doesn’t extend to hosted apps.
If Maidsafe change the client library to be more permissive and/or provide a linking exception, then I can update the license again accordingly.
Release notes:
- Updates license to GPL-3.0, as Autonomi library is likewise (and incompatible with Apache-2.0).
- Adds chunk module and refactors sender/receiver to simplify integration.
- Minor logging improvements.
Github: Release v0.4.6 · traktion/AntTP · GitHub
Dockerhub: https://hub.docker.com/r/traktion/anttp
Cargo: cargo install anttp
I’ve pushed a new v0.5.0 release out today:
- Updates to use Clap for CLI argument parsing, allowing named arguments, in any order. This provides much more flexibility and will avoid breaking CLI changes going forward.
- Changes default download thread count from 32 to 8 to avoid networking issues on some routers/connections. The ‘-d’ argument can override this to the old default or something else.
- Updates dependencies to latest/recent versions, including Autonomi libs 0.4.5.
- Fixes issue where files not found kept the connection open indefinitely, instead of returning a 404 to the client.
- Fixes a panic in the chunk sender when the client closed their connection. This is now logged and handled gracefully. Clients seem to often start a download to retrieve the header, then close the connection, causing this state.
- Improves documentation, including new CLI arguments and examples of how to configure a browser to proxy to AntTP.
- Adds a reference to PubAnt.com for instructions of setting up an Autonomi website.
- Providing a static directory is now optional and will not log errors when it doesn’t exist.
It’s mostly dependencies, minor fixes, improved defaults and documentation, but I’ve bumped the minor version as the CLI interface has been changed. I didn’t want to surprise anyone with this breaking change!
Usage: anttp [OPTIONS]
Options:
-l, --listen-address <LISTEN_ADDRESS> [default: 0.0.0.0:8080]
-s, --static-file-directory <STATIC_FILE_DIRECTORY> [default: ]
-w, --wallet-private-key <WALLET_PRIVATE_KEY> [default: ]
-d, --download-threads <DOWNLOAD_THREADS> [default: 8]
-h, --help Print help
-V, --version Print version
Dockerhub: https://hub.docker.com/r/traktion/anttp
Cargo: cargo install anttp
Just a heads up for those following this thread - the futures::stream
library used by AntTP to stream videos, audio, large files, etc, has now been spun off into its own library: High-level datatypes library - #38 by Traktion
This allows other Rust devs, especially those using Actix, to easily take advantage of the streaming feature.
Pushed v0.5.1 out today, with refactors and fixes:
- Refactored to use the chunk-streamer library (extracted from AntTP code base).
- Patches issue where archives uploaded in Windows have a forward slash delimiter instead of a backslash for Unix (Mac/Linux). This looks like an ant CLI bug, but this work-around just flips all forward slashes to backslashes prior to resolution.
I’ll report the ant
CLI suspected bug shortly, but this gets around it (thanks @safemedia for reporting!).
Github: Release v0.5.1 · traktion/AntTP · GitHub
Dockerhub: https://hub.docker.com/r/traktion/anttp
Cargo: cargo install anttp
Hey, when you talk about:
… does it mean that when uploading, the self encryption is done in a streaming manner? I’ve been trying to upload a large ZIP file, but cannot do it because I don’t have enough RAM to encrypt it. Would AnTP help in this?
Right now, chunk-streamer is only for downloads.
In AntTP, it allows large files to be sent to the client/browser chunk by chunk, as they come in from the autonomi library. It also allows multiple chunks to be downloaded at the same time, then sent to the browser in order.
I’m not sure if it could help uploads. AntTP accepts file uploads through an async endpoint, then attempts to encrypt and upload in the background. I’ve not monitored resource usage on large uploads, but it uses a similar call to ant
CLI, so probably similar results.
v0.6.0 has now been released and it is a bit of a whopper!
- Adds pointer REST API with CRU operations.
- Adds register REST API with CRUH operations.
- Adds associated app_private_key CLI option to derive sub-keys and ownership.
- Adds the concept of bookmarks as a CLI option, which is a basic pet names resolver (more to come!)
- Adds disable uploads as a CLI option for those who want read only hosting.
- Refactoring to move HTTP request logic to ‘controller’ and service layer code to ‘service’.
- Renamed xor_helper to resolver_service and added support for resolving bookmarks, pointers and registers for public archives.
- Refactoring to move more code into separate crates
- Adds mutable caching for short period in HTML response (60s default).
- Refactorings for resolver_service.rs to use struct for result and associated improvements.
- Reduced info logging to remove noise.
- Adds config to set mutable caching TTL
- Replaced REST API POST/PUT with async calls, returning derived successful values immediately.
Some of the features are general improvements, but many were dependencies for IMIM, so I needed to get them in place ASAP.
The REST API may be subject to interface changes, as it was pieced together pretty quickly. However, it does provide a mechanism to perform POSTs/PUTs (create/update) operations asynchronously, with a derived successful value returned immediately. This hides much of the latency which can be involved and allows clients to assume success. A subsequent GET operation will hit the network and can be used to discover if the operations were successful.
I want to do a bit more to indicate this is what has happened, probably by adding a response header, but it’s a bit WIP and I’ll probably refine as I stress test it with IMIM.
Note that the async tasks will soon be added to a job processor, which will have the potential to block the network operation, until a second application has signed the task. This will provide a 2-factor style interface, to avoid bad apps from storing unexpected data. Ofc, the signing app could automatically sign in some cases to improve UX (e.g. allow batches of X actions to be allowed, allow all from app Y, etc).
There is now also a flag to turn off uploads altogether for public proxies (which was a feature request).
For REST API GETs, I have added mutable data caching, which has a 60s default TTL (can be overridden in a CLI argument though). This results in subsequent GETs retrieving the data from memory until it expires. Likewise, this 60s TTL is also used for HTTP caching headers to encourage the browser to re-use the same data for up to 60s.
While the cache is short lived, it makes a big difference to page load times, as the same API data may be retrieved many times.
Note that this new caching complements eTag caching, which is still a huge help. If the content of a mutable target is unchanged, once the target has been retrieved again, the target data will not need to be downloaded again - the browser still knows its the same content!
Moreover, the HTTP requests for archives and chunks benefit from pointer and register integration. AntTP will now find the pointer target or the latest register value, resolve it, then download the files/data as before. This applies to all file types, including videos/music/text/images, etc.
After the above, I thought it would be a shame if we then just had even longer URLs to share… so I created a basic pet names / bookmarks system too. By default, I’ve just thrown in ‘imim’ and ‘traktion-blog’, which resolve to a pointer and register respectively, which in turn resolve to data/files on the network.
What does that mean? Well, assuming you have your browser proxy setup, you can just got to this URL to see my blog!
http://imim/blog/traktion-blog
Articles can be linked as follows too:
http://imim/blog/traktion-blog/article/dog-food-is-delicious.md#article
All a bit more readable, right?
I want to expand on this ‘bookmarks’ concept to accept addresses on the network for these, which then allows a more genuine ‘pet names’ experience. For now, you can specify your own key/value pairs from the CLI.
What else does this mean for IMIM? I’ll leave that for an IMIM update post…
Github: Release v0.6.0 · traktion/AntTP · GitHub
Dockerhub: https://hub.docker.com/r/traktion/anttp
Cargo: cargo install anttp
(P.S. I had a dependency issue with the aarch64 build, so I’ve just dropped it from the release builds for now while I investigate the cause. The old aarch64 versions will still be fine though.)
The above link is the link to the AntTP tutorial
Tutorial: AntTP
AntTP acts as a web gateway for the Autonomi Network. It receives standard HTTP requests from users or applications and translates them into requests for data or archives stored on the decentralized network. It includes features for resolving network addresses, serving files and public archives, managing uploads, and caching data for faster access, all based on its application configuration.
–
I hope you don’t mind me posting this. I’ve found this really helpful to get and understanding of simple codebases. They have 9k stars on githhub.
Below is a link to the service to generate a tutorial for any codebase. It is free to use currently in beta.
Will this be packaged to be more user-friendly in the future, like only have to dubbelclick on anttp app and start using the app or as a browser extention where these things happens in the background?
That is amazing! I’ve never seen that tool before, but it absolutely nailed it! I read the whole thing.
It reminded me of a few more refactors I’d like to make too, but way it broke things down by example was mind blowing!
I’m definitely going to use that on unfamiliar code bases too!