What is DLN?
DLN (DevinLittle.net) is a collection of applications, services, and libraries designed to provide a consistent platform for communication, file sharing, productivity, and experimentation.
It originally began as a small collection of personal tools. It eventually evolved into a shared ecosystem of reusable services and client applications. Rather than building each application independently, DLN provides common infrastructure that can be reused across multiple projects.
At a high level, DLN consists of:
- Client applications, such as the CLI, web app, and Qt UI.
- Backend services responsible for authentication, notifications, file sharing, End-to-End Encrypted private notes, and other platform features.
- Shared libraries that provide common contracts, protocols, and functionality.
- Deployment tooling used to operate and distribute the platform.
Although many components can be used independently, they are designed to work together as a cohesive system.
Goals and Design Philosophy
I’ve designed DLN around a few core principles:
Shared Infrastructure
I essentially wanted a google workspace of my own. I wanted to create a place where I have 1 login and all my services are connected. Instead of creating a bunch of 1 off tools, I have 1 centralized place for all my services.
Event-Driven (the live feeling)
I love when applications have this feeling of being alive and I also love the user experience of not needing to refresh in order to get up to date data, so I built these applications with my Event-Driven ideals in mind.
Lightweight
I wanted both clients and servers to be very light.
The whole server stack can run on a Raspberry Pi Zero 2 along with a client.
Clients can run on anything, and my descision to choose Qt can enable clients to sit in the background of your OS without offering much overhead in terms of CPU and RAM usage (yk with the whole ram situation its key that dln-ui doesnt just suckup 5 Gibs of ram lol)
Platform Consistency
I wanted to offer many platforms, so keeping data flow consistent is required and something to boast about too.
Self-Hosted First
I run many self hosted applications on my own homelab and if people dont like having all their encrypted notes on my databases then they can deploy their own DLN and just change the api_url in both the frontend and clients to use their Infrastructure rather than my own.
Repo Structure
Obviously DLN (DevinLittle.net) is open source and I want to take a moment to explain the repository structure.
Apps
This directory contains the source code of all the clients DLN offers.
Chart
- Is currently empty But would have the helm chart
Crates
In FOSS projects it’s common to see a folder titled crates which is equivalent to the javascript packages directories. Crates contains rust libraries that other crates/binaries in this project rely on. The biggest/most important crate in this folder is the dln-core…More on that later in this book
Dist
The Dist dir contains everything related to packaging…Thats kinda it.
Docs
Docs contains this book. To note, there are docs directories inside some crates/bins in this project (ex. inside backend-common there is a docs dir), these include markdown files which are imported during the rustdoc stage, but that is just something I wanted to mention to clear up confusion.
Frontend
Currently the frontend directory contains only 1 subsequent directory, which is titled website, this just contains the web app for DevinLittle.net and maybe if I have more web frontends, try to have two different versions of the site, ect. idk tbh?
Packages
I explained this at crates
Scripts
Scripts is a little bit more complex to explain without overloading you with buzzwords but, its mainly used by the build and packaging processes so yeah.
Services
Contains all the backend services…That’s literally it. I couldn’t explain anymore than that. All services do get explained in a different chapter, so look there for more information on services.
Identity
hi there! Please move to the next page
User
A user represents a person interacting with the DLN platform.
Users are the primary identity object within the system and are used to associate data, permissions, sessions, and communication channels with a specific individual.
Every user is assigned a unique User ID and may have multiple active sessions simultaneously.
A user’s identity persists regardless of how many devices they use or how many times they authenticate.
User ID
A User ID uniquely identifies a user within DLN.
Unlike usernames, which are used for display purposes, User IDs are intended for programmatic identification.
Services use User IDs when storing ownership information and associating records with a specific user.
User IDs remain stable throughout the lifetime of a user account.
Session
A session represents an authenticated client instance.
When a user authenticates, a session is created and associated with that user.
Because a single user may access DLN from multiple devices simultaneously, multiple sessions may exist for the same user.
Sessions are heavily used throughout the platform for routing, presence tracking, and device-specific communication.
Session ID
A Session ID uniquely identifies a specific session.
Where a User ID identifies a person, a Session ID identifies a particular authenticated device or client instance.
Session IDs allow messages and events to target a specific device without affecting other active sessions belonging to the same user.
Access Tokens
An access token represents an authenticated session.
Clients include access tokens when making requests to authenticated services.
Access tokens are intentionally short-lived (15 Minutes to be exact) and are designed to be refreshed periodically through the refresh token mechanism.
Refresh Tokens
Refresh tokens allow clients to obtain new access tokens without requiring the user to authenticate again.
Unlike access tokens, refresh tokens are long-lived (1 Year of validity) and persist across application restarts.
The refresh process allows users to remain signed in while reducing the lifetime of actively used access credentials.
Roles
Roles define what actions a user is permitted to perform.
Roles may exist globally or be scoped to a specific service.
This allows permissions to be granted independently across different areas of the platform while maintaining a consistent authorization model.
Communication
hi there! Please move to the next page
Channels
A channel is a logical communication destination within the notification system.
those destinations can be:
- a global channel - a channel all users are subscribed to, authenticated or not
- a special user id channel - only users with that User ID will receive the message
- a admin/role channel - users with the admin role will only receive the message
Channels allow messages to be targeted at specific users, sessions, roles, or groups rather than broadcasting every message to every client.
Clients subscribe to channels when connecting to the notification backend, and events are delivered through those channels.
Events
Events (also referred to as Messages) is a message that represents something that happened within the system.
Events allow services and clients to react to changes without requiring direct communication between every component.
Events are distributed through the notification backend (notification service) and are used by services such as GradeGetter, Nanopass, and Smalltalk to communicate changes to connected clients.
Namespaces
A namespace identifies the category or domain an event belongs to (often a service).
Namespaces allow events to be categorized and routed/processed accordingly.
Clients use namespaces to determine how incoming events should be handled.
Routing
Routing relates to how messages (events) are handled.
Routing is required for messages to be handled.
Messages are routed on the client in DLN and allow for the live feel of DLN.
Presence
Clients
A client is an application that provides an interface through which a user interacts with DLN.
DLN clients are built around dln-core, which provides the shared client-side implementation of all DLN features crucially including DLN’s communication and authentication model.