Digitapes Holding Services

digitapes

In this article we’re going to implement a very basic holding service, as of the design today (3rd June ‘24).

We know what a digitape looks like from the digitapes-model article, so we’ll start by looking at what a holding service needs to do and how it can do it.

At the basic level, a holding service will need to:

  • List tapes that are available
  • Import and Export tapes (to transfer data to other holding services)
  • Create a new tape
  • Edit the metadata on a tape
  • Add or remove media to a tape

Things that could be part of a holding service, in addition could be:

  • Authenticating: signing into a service
  • Adding friends as collaborators on a tape
  • Billing for usage
  • SSO/0Auth to other services (generators, etc)

The basic “need” that we’re meeting is that there’s a cross-compatibility within digitape services. A localhost shell-scripting digitapes script should be able to make a digitape that it gives to some generation service; whether that service needs an account or not is the concern of the service and digitapes.

Writing a basic holding service

I’m going to write dbhs (digitapes basic holding service) using dart-lang because I want to practise dart and because this is more “proof of concept” rather than production ready code. If you want to make a better holding service in go-lang or such, feel free to and let me know about it.

For the basis of this design, it will offer two interfaces to manage digitapes; a REST service and a CLI. It will store the digitapes locally and not use any database, login, auth service, etc. This is only a basic service to get the point across, and to help develop against when we get up to mobile phone apps.

Authorization and Authentication

While we don’t quite have a mobile design, there’s room to think about what we might need in terms of a hypothetical mobile app.

For our simple example, we can simply connect the mobile app to some service and start uploading, but what do we do in terms of authorization? how do we allow authentication where the mobile app can authenticate against any number of services without having to “log into” each of them with some multi password flow?

An easy and simple solution could be that we use a basic public/private key pair from the app, and allow the service to manage the authorized_keys part. This is how most SSH/SCP sessions work, and means the mobile app does not need to “log in” - it simply provides the public-key, and the service is responsible for authorizing it.

I like this approach as it’s very simple and could tie into a fairly easy to use flow. A similar option seems to be mTLS which is used as a two-way asymmetric key exchange, but at the moment i’m at a loss on how to implement it in a way that is nice and easy to use (for implementors and for users).

For now, we’ll shelve the auth requirements, and I’ll come up with a design in a seperate article.

Code and feedback

The source code for what’s discussed will be available on the digitapes github, which is at https://github.com/Dotrar/Digitapes