Here is a patch to add dicod service type to Guix Home,
and here are some things I wrote about the process.

---------------------------------

#+title: Extending Guix Home
#+author: Mitchell Schmeisser <mitchellschmeisser@librem.one>

I recently learned of a new [[https://www.masteringemacs.org/article/wordsmithing-in-emacs][Emacs feature]] ~M-x dictionary~ which
allows you to connect to a dictionary server using a special protocol.
Out of the box Emacs can reach out to places like [[https://dictionary.com][dictionary.com]]
to look up the definition of words.
This is convenient, but it is a [[https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html][Service as a Software Substitute]].
There is no reason why I cannot run my own dictionary server and
protect my privacy.  After all, you never know when the NSA will try
to change the definitions of words to make you look foolish.

It is very easy to run one of these servers in a freedom respecting way,
simply get your hands on a copy of GNU Dico and your dictionary of choice
and run ~dicod~. Most people like to run ~dicod~ as a service which is
managed by the init system.

To my dismay every tutorial and blog post required the user to
use ~sudo~ to install programs and modify the init system.
This is less than desirable.

A wonderful, often under-rated, feature of GNU Guix is /unprivileged/
package management. An even more under-rated feature of GNU Guix
is /unprivileged/ service management provided by [[https://guix.gnu.org/en/blog/2022/keeping-ones-home-tidy/][Guix Home]].

* Guix Home Services

Guix Home allows you to extend the declarative Guix model to your home
environment.
You can install packages and dot files transactionally, making migration
to a new machine painless and consistent.

Unfortunately, at the time of writing there are very few Guix Home services
and most of them simply generate dot files for this or that shell.

Or are there?

* System Services are Home Services

GNU Guix has a ~dico-service-type~ which is very easy to use.
Unfortunately this service type requires system-wide modifications and
requires root.  It is also out of reach for people running Guix on a
foreign distribution where ~guix system reconfigure~ is not an option.

Below is the definition of the ~dicod-service-type~ designed for the
Guix System.
#+BEGIN_SRC scheme
  ;; from gnu/services/dict.scm
  (define dicod-service-type
    (service-type
     (name 'dict)
     (extensions
      (list (service-extension account-service-type
			       (const %dicod-accounts))
	    (service-extension activation-service-type
			       (const %dicod-activation))
	    (service-extension shepherd-root-service-type
			       dicod-shepherd-service)))
     (default-value (dicod-configuration))
     (description
      "Run @command{dicod}, the dictionary server of
    @uref{https://www.gnu.org/software/dico, GNU Dico}.  @command{dicod}
    implements the standard DICT protocol supported by clients such as
    @command{dico} and GNOME Dictionary.")))
#+END_SRC

Here is the definition of the ~home-dicod-service-type~.
The only difference between them is for Guix Home we want to run
all processes as the user and cannot create new accounts.

#+BEGIN_SRC scheme
  (define home-dicod-service-type
    (service-type
     (name 'home-dict)
     (extensions (list (service-extension home-shepherd-service-type
					  home-dicod-shepherd-service)
		       (service-extension home-activation-service-type
					  (const %home-dicod-activation))))
     (default-value %home-dicod-configuration)
     (description
      "Run @command{dicod}, the dictionary server of
  @uref{https://www.gnu.org/software/dico, GNU Dico}.  @command{dicod}
  implements the standard DICT protocol supported by clients such as
  @command{dico} and GNOME Dictionary as a user.")))
#+END_SRC

In general, this is the only difference between a Home Service and a System Service.
System services will generally insist on an account specifically for running a process
and take some steps to create an environment where that account has just enough permissions
to do the job.  Home services all run as the user and so the the user
needs to have enough permissions to do the job. =/var/run= becomes =$XDG_RUNTIME_DIR= or
=/run/user/$(uid)/=.

* Unprivileged, Containerized, dictionary server

Using the code below I can finally look up the definitions of words in
complete, unprivileged, freedom!  This service spawns a ~dicod~ server
isolated from the system using ~least-authority-wrapper~.  It shares
the network namespace and can see it's run-time directory and
read-only configuration file and that is it.

This is nice, but could it be nicer?

#+BEGIN_SRC scheme
  ;; A new database is defined which places the idxdir argument
  ;; in a place writable by the user.
  ;; /tmp was chosen over XDG_RUNTIME_DIR or /run/user/
  ;; because I do not know when this is evaluated.
  ;; guix pull time or guix home reconfigure time.
  ;; I think these are the same in most cases but maybe they're not?
  (define runtime-dir "/tmp/dico")

  (define %home-dicod-database:gcide
    (dicod-database
     (name "gcide")
     (handler "gcide")
     (options (list #~(string-append "dbdir=" #$gcide "/share/gcide")
		    #~(string-append "idxdir=" #$runtime-dir)))))

  (define %home-dicod-configuration
    (dicod-configuration
     (databases (list %home-dicod-database:gcide))))

  (define %home-dicod-activation
    #~(begin
	(use-modules (guix build utils))
	(mkdir-p #$runtime-dir)))

  (define (home-dicod-shepherd-service config)
    (let* ((dicod.conf ((@@ (gnu services dict) dicod-configuration-file) config))
	   (interfaces ((@@ (gnu services dict) dicod-configuration-interfaces) config))
	   (dicod      (least-authority-wrapper
			(file-append
			 ((@@ (gnu services dict) dicod-configuration-dico) config) "/bin/dicod")
			#:name "dicod"
			#:mappings (list (file-system-mapping
					  (source runtime-dir)
					  (target source)
					  (writable? #t))
					 (file-system-mapping
					  (source "/dev/log")
					  (target source))
					 (file-system-mapping
					  (source dicod.conf)
					  (target source)))
			#:namespaces (delq 'net %namespaces))))
      (list (shepherd-service
	     (provision '(dicod))
	     (documentation "Run the dicod daemon.")
	     (start #~(if (and (defined? 'make-inetd-constructor)
			       #$(= 1 (length interfaces))) ;XXX
			  (make-inetd-constructor
			   (list #$dicod "--inetd" "--foreground"
				 (string-append "--config=" #$dicod.conf))
			   (addrinfo:addr
			    (car (getaddrinfo #$(first interfaces) "dict")))
			   #:service-name-stem "dicod")
			  (make-forkexec-constructor
			   (list #$dicod "--foreground"
				 (string-append "--config=" #$dicod.conf)))))
	     (stop #~(if (and (defined? 'make-inetd-destructor)
			      #$(= 1 (length interfaces))) ;XXX
			 (make-inetd-destructor)
			 (make-kill-destructor)))
	     (actions (list (shepherd-configuration-action dicod.conf)))))))

#+END_SRC

* Is =gnu/home/services= an Anti-Pattern?

The code above is almost identical to the code located in
=gnu/services/dict.scm=.  The only difference, as a mentioned, is the
account information.  With this in mind, does it make sense to define
Home Services along side their system counter parts in =gnu/services=?

I believe many services in =gnu/services= can run from Guix Home with
only minor modifications.