Quiz time: Old enough to remember Haml?
To some limited degree Phlex is like Haml -- I know; it's not fair to neither but please bear with me! Haml made it fun and easy to write HTML soup and had it not been for the strict formating I'd probably still be doing it!
Enter Phlex and all of a sudden your old habits die hard - again
Consider this tiny clip:

div(class:"m-2") do
  plain { "Enter Phlex and all of a sudden your "}
  a(href: "https://www.youtube.com/watch?v=2SkYNSKB1aM") { "old habits..." }
end

If you squint your eyes and let them just sweep the code block for a quick look-see? It could fool me - if I dropped the 'end' and added a '%' on the p's and a's :)

(Phlex even has a page in the new beta 2.0 documentation assigned to the difference between Haml and Phlex so I guess it's not all smoke and mirrors)
Anyways with that introduction off my chest let's get this band on the road!

Airborne

First I added the gem to my new-ish Rails project (it's actually running off of the main branch on github - so quite new in fact, but you don't have to be leaning over the edge to join the [phlex.]fun):

bundle add phlex-rails --version=2.0.0.rc1

I willingly stayed in character as the bonus pater familias and did the

bundle exec rails generate phlex:install

So, now I was ready to start porting my components library to Phlex 2.0 – components that I use for index views and forms, mainly and in this post I'll focus on the index views.

Getting the hang of it

"You cannot walk until you master crawling" is a life experience of mine so let's crawl for a start!
The Phlex documentation starts of with building a component but I'd like to introduce you to a slightly different learning curve. We'll build that index action on a home controller – in essence an endpoint like https://app.mortimer.pro/, which coincidentally is the entry to a product that you can read more about https://mortimer.pro

Three Rails files comes to mind: views/layouts/application.html.erb,  views/home/index.html.erb and controllers/home_controller.rb

From the docs we know where this is all going to end so let's do the obvious thing and write what we'd like to have

# controllers/home_controller.rb
class HomeController < ApplicationController
  def index
    render Views::Home::Index.new
  end
end

Reloading https://localhost:3000 immediately confirms what we feared the most – something is missing (and if you're getting that dreaded almost blank screen informing you that there is an issue with security – I have just the medicin for you)!

Try this in your CLI (you could bring one up using [Cmd+j] if you're using VS Code with default keyboard shortcuts on a Mac) bundle exec rails generate phlex:view home::index
Another reload in the browser and we're once again good – kind'a

Inheritance and composition

So far we've managed little besides exchanging html.erb with rb but that is about to change – scouts honour!
Once again let's write what we want to end up having

# controllers/home_controller.rb
class HomeController < ApplicationController
  layout false

  ...8<..

Reloading tell us that the layout went away. We'll fix that

First back in the CLI do bundle exec rails g phlex:component layout

Then follow up with these changes

# views/home/index.rb
class Views::Home::Index < Views::Base
  def page_title = "Home"
  def layout = Layout

  ...8<..

# views/base.rb
class Views::Base < Components::Base
  PageInfo = Data.define(:title)
  def around_template 
    render layout.new(page_info) do 
      super 
    end
  end
  
  def page_info 
    PageInfo.new( title: page_title ) 
  end
end

We are one change short - but before we add that one allow me to introduce you to one of my absolute favorite web services: phlexing.fun
Its service is so simple and yet so powerful: have html -> get phlex
So copy the contents of your views/layouts/application.html.erb and paste it into the textarea with the placeholder "Paste ERB here" and shortly after you'll have a copy-ready snippet of Phlex to paste into your layout.rb
(be prepared to follow the 'prompting' when reloading - your HTML will probably contain a number of calls to Rails specifics - like csrf_meta_tags but Phlex has answers for most)

# components/layout.rb
class Components::Layout < Components::Base
  def initialize(page_info)
    @page_info = page_info
  end

  def view_template
    doctype
    html do
      head do
        title { @page_info.title }
        meta(name: "viewport", 
          content: "width=device-width,initial-scale=1")
        meta(name: "apple-mobile-web-app-capable", 
          content: "yes")
        meta(name: "mobile-web-app-capable", 
          content: "yes")
        csrf_meta_tags
        
        # csp_meta_tag
        # Enable PWA manifest for installable apps 
        # (make sure to enable in config/routes.rb too!)
        # = tag.link rel: "manifest", 
        #  href: pwa_manifest_path(format: :json)
        
        link(rel: "icon", href: "/icon.png", type: "image/png")
        link(rel: "icon", href: "/icon.svg", type: "image/svg+xml")
        link(rel: "apple-touch-icon", href: "/icon.png")

        # Includes all stylesheet files in app/assets/stylesheets
        stylesheet_link_tag "tailwind",
          "inter-font",
          "data-turbo-track": "reload"

        stylesheet_link_tag :app, 
          "data-turbo-track": "reload"

        javascript_importmap_tags
      end

      body do
        main(class: "container mx-auto mt-28 px-5 flex flex-col") do
          yield
        end
      end
    end
  end
end

Agreed, this did not bring us Total World Domination or Peace To All Mankind but we took a decent step towards DRY-ing up and componentizing our views – more on that in the next post, and while I hurry to post that you could give this one a quick skim; it's on DRY-ing up the controller!

Model-View-Control is one of a list of cornerstones in Ruby on Rails and a pattern in general implementation of man-machine interfaces. The C handles the request from the 'man', collects data from the the M (model) that interfaces with data whether it's persisted in some (r)DBMS or elsewhere, and finally handing it back to the 'man' with the help of the V (view) that assists by generating some sort of output whether HTML, JSON, or something entirely different.

How did I (almost) lose the C?

Back in the day there was this thing called inherited_resources that I grew very fond of and as time passed it morphed into this:

class MortimerController < BaseController
  #
  # defined in the resourceable concern
  before_action :set_resource, only: %i[ new show edit update destroy ]
  before_action :set_filter, only: %i[ index destroy ]
  before_action :set_resources, only: %i[ index destroy ]
  before_action :set_resources_stream

  include Resourceable
  include DefaultActions

  --8<--
  
end

I know – I could have put the before_action statements in the include but I like to have just a tad overview of what all the magic is about :wink:

The Resourceable is responsible for setting up required resource(s) for the actions (index, show, new, edit, create, update, delete).

The DefaultActions is responsible for handling a "default" action to any of these actions (and a few more like `lookup` which, BTW, to me is a specialization to the index action).

The result?

My standard "post" controller looks like this:

class PostController < MortimerController
  private
    # Only allow a list of trusted parameters through.
    def resource_params
      params.expect(post: [ :id, :title, :body ])
    end
end

The DefaultActions is a concern looking  – in part – like this:

module DefaultActions
  extend ActiveSupport::Concern

  included do
    def index
      @pagy, @records = pagy(@resources)

      respond_to do |format|
        format.html { }
        format.turbo_stream { }
        format.pdf { send_pdf }
        format.csv { send_csv }
      end

    rescue => e
      HandleError.new(request: request, params: params, error: e)
    end
    
    --8<--
    
  end
end

Sweet, isn't it?

The previous part ended on accounting for the choice of 15% transaction cost. Any number could, in fact, be selected - but the psychological factor is important, and '15' has an almost virgin-like aura, the 1 and the 5 are good together - nothing like all the drama of the 3, the 6, and the 9, the scary 7 or the dubious 2, nor the pompitious all consuming '8'. I forgot the 4 - 'cause, well, you just do 😟

The fine print

Barter is not solved - is it!?

The short answer to that question is: No! People will barter like they do today. If my neighbour is willing to do my lawn and in exchange have me do their dishes, nothing in this universe will be able to control that!

A somewhat longer at it: Barter is a deliberate decision based upon the perceived degree to which one feels getting robbed. A 25% VAT on top of a hourly price of perhaps 50$ will leave most feeling getting robbed pretty good. 15% is still not free beer but certainly a considerable less grivious experience – and with hourly charges perhaps even sliding ever so little, hopefully even less so!

But bartering will never cease to exist – the incentives are just too big. Reducing the risks and friction pertaining to the money transactions, however, will bring down the size of bartering measurable.

GNP will suffer and make us all a lot poorer!

Well - this is where things start getting really complicated!

Gross National Product - Gross National Income as it's in fashion to label it now - is the market value of all the goods and services produced in one year by labor and property supplied by the citizens of a country. Quite a mouthful, right? But rest not - it get's a lot worse - 'cause GDP is favored by many in measuring the real economic habetus of a country; and then there is Gross Value Added. Interested, read on here, or have a tast of the issues surrounding all the calculations and forecasts, like this article explaining divergences between GDP and GVA in the worlds largest population, India.

In Utopia lives only 2 people. One is a farmer growing potatoes and the other is a student learning to be - a farmer perhaps. The farmer hands the student 100$ every month for the student to be able to pay for the potatoes they need to survive. That's a GDP of 100$. Now the farmer increases the price to 110$ – and has to hand the student 10$ more. GDP just rose by 10% ?!? No one grew any more potatoes and neither of the citizens got any richer nor more full!

So - like Utopia - reducing taxes will lower the GDP but this will possibly strengthen the country's ability to compete in markets internationally and leave no one any poorer nor less full (as long as transfer incomes - the 110$ for the student - are equal to the current spending, ie if the above 'story' was reversed and the farmer lowering the price = less tax and thus handing the student 100$ instead of 110$ allowing the student to buy potatoes like before)!

Side effects may be less inflation but that might be offset by increased purchasing power by consumers and, yeah the list goes on!

Allowances and gifts

If 15% transaction costs are added to all money transactions – what will happen to allowances and gifts?

That's perhaps the single most challenging issue, and one that I have no really good answer to!

If my daughter works her butt off scrubbing our kitchen floor and I agree to raise her "pocket money" from nil to 10$ a week, I need to accept that I am in fact paying 11.50 for the floor scrubbing. Furthermore she will have to come to terms with not getting her full measure of sweets at the candy store – because she cannot afford the entire bag of sweets at 10$ but only 8.695$'s worth of candy.

In the bigger picture (for the greater good) I do, however, consider this a minor snag in the design! Leaving back-doors open certainly will corrupt the system and render it useless in a very short time – so it's either all or nothing, as I see it.

Foreign trade will be endlessly more difficult!

Not by any measure, no!

Let's start with sales. Company A wins a big tender for erecting playgrounds in 10 german cities. The german "Länder Amt" is provided with an IBAN number (the way most money is wired from buyer to seller, today) pointing to Company A's escrow account in the Nationalbanken, and when Company A wishes to transfer the payment to their digital company wallet, the 15% transaction cost will be added.

Procurement works in exactly the same way. Company B buys sugar cane from Cuba and transfers an agreed upon money sum to their escrow account in the Nationalbanken. The Nationalbanken dutifully informs the cuban seller of the money sum being present and ready and now the seller can see to the cane getting shipped to Denmark with no worries about whether Company B has any intentions to fault the payment.

In fact foreign trade will benefit immensely from this scent-added-to-money disruption for one by making it ridiculously easy to enter into contracts with foreign buyers/sellers. Every transaction is now supervised and backed by the Kingdom of Denmark thus cutting out all the 'middle-men' in the process!

Banks will not like it!

No, no more than newspapers liked the advent of the Internet and social media! They are free to lend money but I understand that the consequences will be a 'harsher environment' to operate in. C'est la vie

This will get bogged in bureaucrazy!

Bureaucracy is a german invention - or rather, Max Weber is considered to be one of the first to popularize the term! An efficient organization processing administrative tasks and the procedures they follow when decision-making – an office analogy to the manufacturing assembly line.

Bureaucracy by itself is merely an efficient way of organizing the completion of work tasks, and with a proper mission and just set of rules to run this bureau there is absolutely no reason why stinking money should become bureaucrazy!

I acknowledge the dangers facing this Gordian Knot cutter, like politicians realizing how easy it will be to turn the transaction cost nob versus asking their public service spenders to revisit the budgets or telling their voters to lower their expectations as to what returns they can expect from the public sector.

What is next?

I have a post in the making detailing the implementation - stick around for that

😊

In part one we learned the only right way to perform money transactions was to add a scent to money – make it entirely digital!

We ended with me positing that the only way would be for the National Bank to do a different job...

Make money stink!

I've linked to the solution above in part I, but it really is the only way! If we have to do a better job at overseeing money transactions making sure that they are legit and executed properly, we need to bring the C-gun -  C for crypto (inspired at least). There are not enough hands in the entire Kingdom of Denmark to manually supervise the transaction of money. Basta!

In a few short years Denmark is to have a fresh set of bank notes. Perhaps we should not -

- perhaps we should have only one "note" - a specially crafted bank note the size of a credit card more or less. Housing a key generator and a few other digital artifacts which working in concert will be able to offer the owner a ways to hold "cash" - in effect being a digital wallet. Before you even voice it: a pivotal task will be to provide this wallet with a host of failsafes, booby traps, and safety mechanisms to reducing the number of mis-uses.

Going full digital money-wise will be about as big a disruption as the first smart-phone. The gains are monumental and will easily cover the necessary increase in compensations paid to owners unlucky to be subjects to what ever small percentage of criminal activity even so.

This is far to important to be handed on a silver plate to the private sector! We cannot make the mistakes of yesterday again! Cases like the telco's, the energy sector, postal service, the national credit card service (danKort), and selling the mortgage companies to a select few banks!

'stinking money' must be controlled and run by Nationalbanken – and built by danish owned and employed personel. Too important.

Tax Heaven

One immediate gain would be a considerable tax cut! With all money transactions suddenly being transparent - an even 15% "tax" on all transactions would revolutionize all sectors! Consider this:

• buying foreign goods would automagically induce 15% "import duty" – not really but the equivalence of; buying those same goods from your local supplier would cost you 15% vat – not really but it would work just like. There would not be any reason for keeping a tab on incured vat costs. No refund - no reverse vat - no nothing; just a cost like gaz on the trucks or heating the offices!
• paying workers hourly wages would automagically add income tax. Paying your workforce 10$ an hour would add a dollar fifty in "transaction costs" but then again: that'll be all there would be to it! No reporting, no statements, no controls! And - should any governmental agency pause to ask questions, it's all there in the money trail! Where every single cent came from and who benefited from receiving it.
• no income tax statements - not for you and not for your business, no statements at all. Because the "taxes" will long have been collected - and probably spent too 😂
• having your private home renovated by your neighbour and his handy son would add 15% to their asking price for the job (see barter below)

What's the net "cost" to businesses? They'd loose 15% on all purchases but save 25% VAT on all goods/services sold - that goes for the markup too! So buying fashion tee's in India on the cheap at 2 euros and 13 cents (and by the way: yes that is in fact the cost of a fashion designer brand T-shirt) and selling them at 100 euro would net them a substantial win! They'd obviously have to pay 15% once they wanted to enrich the shareholders - but still a considerable win. They would pay considerably less to employees (15% in stead of the current 40-60% income tax) which would allow employees to ask a more modest hourly wage/monthly compensation due to a sizeable increase in their purchasing power (because businesses would be able to compete at a lower price point selling to consumers).

With no deductions, tax rebates, reversed vat schemes, and an incredible amount of laws and regulations being null and void, businesses would not be required to submit statements - each transaction would be settled at the moment of payment processing - and thus would save on accountants, book-keeping, consultants and controllers! The number of work hours spent on chores not making the coffee taste better is mind staggering. With just 1 hour spent on book-keeping, submitting statistics, controlling, more per business per week (and that's a very defensive guess) we end at 300,000+ hours a week! Allowing for digitization to swallow the better part (let's apply the Pareto for good measure) we're still left with 60,000 hours. That's well beyond 3M work hours/year - or 600M in saved costs for businesses (and that number is way off – a better guess would be 10 fold, but I reckon it proves the point anyway). Just by "adding a scent" to money 😉

Public tax administration will be able to focus their attention (and resources) on training AI systems to follow the money trails (follow the stink to paint the picture in a more odorious way, so to speak) and solve issues where transactions have gone wrong for what ever reason (technology issues, mischief, ID10T errors, more)

Wait! What's with the 15%?

Will 15% transaction costs really be able to cover all taxes?

Danish businesses have a total turnover of some 500,000,000,000 each month give and take - an average gross margin of 45 will be a huge approximation but let's keep it in broad terms – which equals costs of some 275,000M; of which 15% is 41,250M and multiplied by 12 months leave us with roughly 495,000M. At present some 3,000,000 are employed and their average income is 370,000 pr year; 15% of which is a total of some 166,500M. That's a total of 661,500M a year in transaction costs.

Hey - hey - hey! You will never get away with asking corporate Denmark to cough up 30%! I wouldn't dream of it! In fact I'm asking businesses to keep more of their money. Sure, they will pay 15% on their costs, no matter what the money is spent on - that's gonna piss off some. But they get to save big time on their reporting, controlling, and submission of statements; and they get to pay way less income tax on their employees, a heavy burden which is going down from 40-60% to a mere 15%.

We left 225,000M on the table every month (the gross margin of businesses, remember?) and it's highly likely that a fair share of that will be offered as dividend to owners and shareholders. Let's make a defensive guess at 50% - which will net us another 202,500M in transaction costs (tax) a year! We'll have a grand total of some 864,000M to "redistribute" – whether that is enough is a totally different story.

Because: at present (2023) the public budget was some 1,313,384M of which 715,510M was used on consumption (wages, more) and 481,256M was transfer incomes (spent by households). 396,000M was spent on wages and at least 40% would be taxes - removing that and adding 15% transaction costs will reduce the overall figure to 273,240M, moving the overall needle from 1,313,384M to 1,190,624M. Like our Utopian example we can reduce the transfer income‚ without reducing the purchasing power, by -20% + 15% => 442,755M, further lowering the grand total to 1,152,124M. A few similar changes could be made but we'd still be at least 200,000M short.

A couple of issues are important to consider

• we reduced VAT from 25% to 15% - increasing transaction costs on a filtered set of transactions starts the journey down the rabbit hole of complexity and loss of transparency! Either prices will drop and consumers are likely to spend more - or businesses will add another ~10% margin; which anyway will come back with 15-20,000M.
• reducing complexity in the entire control chain (in fact more or less all together) likely will reduce staff considerably.
• sourcing "taxes" will cut substantially on arrears (tax payer debts) and largely remove non-taxed incomes all together.
• disrupting money transactions could be a kickstart to disrupting a number of public sector customs
• policy-makers will be wise to 'test' the volatility of this transaction cost – starting off slow to maximize success from the get-go

Learn of the fine print in the next part

The best way to launder money obliviously is to keep it clean in the first place!

"But I'm sitting on this huge pile of stinking money!" – you tell me. Well, then you have a job to do!

My first advice for you is to go find yourself someone else with that problem too. You could swap money so to speak! His money stinks and so does yours but the funny thing with money is that once they change owner all the dirt and sweat (and blood?) rubs off all at once! Lend the other guy your money and in return they could lend you theirs! Set up an i-owe-you in a single sentence:

I, John Doe, owe you, Jane Doe, US$ 200,000 which I promise to repay you in exactly 1 year with US$ 200,000.

No interest hence no tax - just the principal.

As long as you "swap" equal amounts of money it's like you didn't at all and it's like they did not exist in the first place.

You could allow friends to join and widen the scope so to speak. Eventually they would start referring to your 'band-of-brothers' as a bank – in fact that's what actually happened. Some guy would lend someone else their money and have it paid back later!

Disclaimer! It's probably the worst idea in the history of money laundering schemes – don't go that way; I shared it only to prove the point: money don't stink!

Nationalize money -or?

At the moment Danish TV2 is streaming Den sorte svane (The Black Swan) a limited series documenting how relatively easy it is for criminals to avoid tax, VAT, and laundering of money.

Meanwhile in Folketinget (the Danish Parliament) politicians are debating (I'm joking - they are not! They are debating their own mishaps on Instagram! But they should...) what to do about the growing number of 'cold hands' in the public administration - some 100,000 with 13% being new hires since 2016 (the total number of employees in public service is a mind blowing 750,000+, mind you). With pricey new IT systems to support the tax and VAT administration it has been necessary, allegedly, to hire an extra 2,000 pair of hands in this department alone! Speaking of tax and VAT; fighting crafty business men exploiting the Danish Tax Code also takes a hefty toll on public finances.

In a previous post I mentioned the banks having their field day with off the charts returns due to surcharges and rising interest rates. Credit card companies hate to be left alone at the station so they try to keep up on the price hike offering small business owners no easy way out when wanting to provide easy ways for customers to pay for goods in their stores, with price increases on payment processing in the double digits.

Let's for a very brief moment pause on that last sentence! A payment processing when all curtains and mirrors are pulled back goes more or less like this:

C1: hallo C2!
C2: hi there C1!
C1: can I have you put 20$ into account #1234?
C2: sure! Consider it done!
C1: great! I owe you 20 bucks!
C2: sure do! Noted!
C1: thx - have a nice day!
C2: U2!

It's obviously the "happy path" and all sorts of mishap may clutter the process but that's worth another story! Bottom line is that the payment processing is nothing more than 2 computers agreeing on submitting vis-a-vis receiving a number (a currency amount) and – for the receiving computer – an account identification. Optimized it's less than 10 Internet packets, an infinitely small cost added to perhaps 50 CPU cycles, an even smaller cost. A total of less than 1 cent (even if we include depreciation on the hardware and software included, energy, and man-power to keep the darn things running. Just so that you know what we are in fact talking about!

One way out would be to ask the Nationalbanken (The Danish National Bank) to setup shop and start running a cheap payment processing service - and lending money at fair rates - but there is not much evidence to support the public sector being good at running businesses!

The only way Nationalbanken could do a better job would be if it were to do a different job!

Learn of what job that could be in the next part.

Sorry for the pun 😎 - but in all fairness it isn't like I just dreamed it up (or picked up the saying back home where I was born - close to fishermen and farmers known to be rather adept to bartering); the Roman emperor Vespasian in fact is attributed the quote pecunia non olet (money do not stink - meaning it does not matter how you came about the green bags, their value is the same)!

But just stop of a second and consider what would be, if money did in fact ‘stink’!

What would this ‘stink’ be? You wouldn’t actually suggest bank notes to be dipped in some sort of fragrance now, would you? Certainly not! But let's leave the implementation for now - no matter how much I'd like to focus on the technical side of things.

First of all, tax evasions would be a thing of the past! Every single euro, dollar, renminbi created will carry a ledger and when you receive 5 cents, each cent will have your name attached to the ledger.Should you later that same day hand two of those cents on to someone else, their name will be added to the ledger of each of those two cents. With me so far?

Secondly, stealing money will be next to impossible! With your name imprinted on every cent it will be impossible for anyone to forward 'your' money to a third body acting – at least doing so 'in good faith'.

Finally money can be "programmed" for particular spenditure. The traditional helicopter money being spent by governments in crisis situations will not be needed anymore. Governments will be able to assign money for very particular purposes. Rent, energy, food. It's a revival of the tried and tested "food stamps" albeit with one very essential difference: you cannot build black markets with this kind of food stamps. 5 euros assigned to you for buying meat. Of cause you can buy the meat and then trade/barter that - but that's a different story.

I reckon you're left with questions - a lot of questions.

Who will create the money? Anyone could issue money (and probably should) and they would add their own name to the top of the ledger - for anyone later receiving the money to see whom to turn to in order to exchange the money for some other value asset. Most will, however, probably be created by national banks.

How will money be exchanged? Attaching a physical ledger to every cent obviously will not fly! Money will (go on) being exchanged electronically using digital wallets. Consumers are so used to it by now that anything else will certainly not meet with a happy ending.

Will we still use VISA, Mastercard, more? Well, that's a tricky question! The basic service is providing the buyer with an easy way of paying while avoiding to carry around cash money, and at the same time afford the seller an easy way to accept payment without getting their teller stuffed with cash money (both parties are happy to being less prone to thieves). This basic service is easy replicated by a single computer handling millions of transactions easy minute.

That's not what makes VISA bag 30B US and change in 2023. They operate as money lenders too – and that business will stay; but the 'card business' will change!

Who will profit from this 'stinking money'? Well, people who did come by their wealth in dubious ways (stealing, drugs, trafficking, more) probably will not, as well as banks, debit card services, (cash) money lenders, and a whole industry of scammers. Once consumers get used to pay with "stinking money" you will always be able to follow the money trail. Buying a second hand sofa will not require you to ask for the original receipt - just ask to see the ledger!

Will it be the end of the "snake oil business"? Probably not, but websites selling 10 dollar gadgets that they source in China at 50 cents will likely be in for some hardship!

Is that not going to disrupt trade altogether? In some ways, sure! Businesses that provide value will always prevail! If you package a product or service with added value through customer service, on-site support, installation, more – customers will favour your business; if your pricing is right! In fact trade will flourish because sellers and buyers will be able to do transactions cheaper and faster, and safer!

What are the downsides? Let me be honest: there are a few!

1. unemployment: Tax officers, bank clerks, ATM repair men, commercial lawyers setting up trade contracts
2. governments watching you: to many if not most having the government keeping too close a tab on your activities is less preferable
3. something new: the biggest downside (apart from denying, those accustomed to enjoying the power of being in control of other peoples money, that luxury) probably will be a mental/psychological one; new ideas and new ways of doing things usually takes a very long time to get a foothold

Is this at all possible? Read about Ripples In The Fabric and a few previous posts on this blog, about the subject and then decide for your self.

What in Heavens is this post about? Ripples, Fabric? Have I gone mad? No! This post is about what we can use the previous posts for; with trust what can we achieve? First I'll touch on The Fabric, how the generic market economy is a spiders web of depending and interconnected services, and then I point to what disruptions may lie ahead. Finally I will introduce a train of thought -

Demise of The Market Economy

The global economy is majorically interconnected market economies – and some that aren't but might as well be (China for all, but even places like North Korea is deeply dependant upon the rest of the world) based on money and the supply / demand mantra.

This interconnectedness starts in your living room more or less! It starts with you being interconnected with your partner (perhaps not but then with the guy you've rented the flat of, or the company where you've bought your shiny new 50" LED TV  with only a few euros up front and the rest in 36 easy installments), and it keeps going all the way to the TV factory in South Korea, the cement factory that produced the cement for the concrete poured into the foundation in the basement of the high-rise where you live, the truck drivers that moved your furniture from the old apartment, the baker around the corner, and by now I think you get the picture. What keeps all these tiny wheels in place? Money.

Like the song - money makes the world go around - and it's actually true! Goods change hands and cash the other way. It used to be barter - you'd bring eggs to the market and end up with 2-3 knitted woolen sweaters, that you'd exchange for a goat, and so on. Later you'd carry gold pieces, then silver coins. Not that many years ago most kept a fair pile of bank notes in a secret place. Now you will have a digital wallet with some bizarre labeled crypto currencies. Each money moniker transformation did leave you just a tad more convenient. Barter could be such a hassle when no one would take your latest exchange of your hands (no demand). Gold pieces could be heavy to carry when you would be on a shopping spree perhaps buying a big plot of land or paying off that army of yours. Green backs always presents a threat if you take them to the wrong side of town (a lot of demand and not any consideration for your well-being).

Expansion of The Fabric (the interconnectedness) had two drivers. Money being more and more easy to move - in more technical terms you could say that the cost of transactions has fallen since like forever. Particularly since italian scientists 'invented' modern book-keeping in the era of The Rinascimento the cost has dropped increasingly fast. Why? Because now you did not have to bring "cash" but would just settle in the books and then someone who owed you money in that place or near by would go and settle your "conto" in your place and you'd then tear his IOU to pieces and toss it in the open fireplace (saving you from risking being robbed on the way as one of the costs disappearing). The other driver happened a few hundred years down the road, in Scotland - when Adam Smith described the division of labour / specialisation. Whether industrialisation precursored specialisation or it went vice versa is perhaps of less relevance - increasing wealth gave way to new ideas and methods were tested and they again provided even bigger returns.

I will not pretend to be able to squeeze 4-600 hundred years of economical, sociological, theological, basically human history into a 3 sentence explanation/characterisation, suffice to say we've landed at a level of interconnectedness that obviously is dangerous! One ship making a bad turn hit the global economy by $6 - 10bn a week, and that was just to top off a global market entrenched while spending estimates of $12tn costs fighting a pandemic putting on clear display how fragile and helpless most economies, nations and indeed individuals have become, eg. 50% of households not being able to sustain basic consumption for more than 3 months of unemployment.

Road Bumps Ahead

Everything revolves around money - and that is increasingly less a blessing as automation, digitalisation, and de-globalisation progresses. Pressure on money-markets and currencies, the core building blocks of  market economies. Battling the climate changes, money-laundering and other tax evasions, national strategies to de-globalise with huge implications for the regional specialisations of markets and industries, and the list goes on. This is The Fabric and the many ripples that we can observe here in the middle of the 20's.

Globalisation never was and never will be the answer - as foreseen by the likes of Kenneth Galbraith. https://en.wikipedia.org/wiki/Comparative_advantage

Specialization is not the way forward - https://www.theaustralian.com.au/business/business-spectator/news-story/why-industrial-strength-is-born-from-diversity/68b45318e3d9dcbff41a8d7a8ad4e65a

The Puzzle Solved

It's no coincidence that I focused on trust in the first post of this series! Would you trade with someone you did not trust? Would you pay them? Take their money?

Voting

Like we established, trust is the corner stone to solving the puzzle! Once that one is in the books we can take on bigger bites. The first and equally important stone is direct democracy like they are used to in Schweiz. Current polarisations and rigging of elections with losers trying to overturn results has to end or we all risk being sent back to the stone age, literally (most experts concur that a nuclear war will end modern civilisation as we know it – not because of radiation necesssarily but famine and no clean drinking water). Direct democracy is not a viable solution bar the smallest local communities, because of the costs of setting up polls. It so happens that our Pigeon tokens trust model will allow us voting every minute of the day almost for free!

Insurance

I'll wage a decent sized cold beer you didn't see this heading coming 😅

Paying for someone elses ill fortune is labeled insurance in some markets (like USA) and socialism elsewhere (Scandinavia).

If we could all vote on every claim - and all be granted access to considering the circumstances to the claim - would we vote fair? I am 100% undecided, maybe maybe not. It's a fair argument that those of limited means will have a hard time convincing those well off. On the other hand - insurance industry is doing pretty darn good, with returns on equity ranging from 12 to 50%, and mind you, in an industry with a global equity mass of US$ 35+ trillion. Big capital gains - in Denmark alone insurance companies raking in some US$ 2bn in fiscal 2021. Adding the substantial costs running insurance companies (some of the most digitalized and efficient companies operate at 14%) - again in Denmark, will add in excess of US$ 5bn.

Savings & Loan

Like the next section on payments it is a walled garden guarded heavily by a select few organisations desperately trying to fend off any disruptions, and with good reason! Banks are a US$ 6bn profit business – in Denmark.

If we add the previous 7bn we are at 13bn - which arguably is a fair bit more than change

Payments

An entire industry (banking) is doing tremendously well handling something so mundane and, with the current technological advance, simple as - payments. One shop owner described it like this:

Banks used to handle (and pay for out of their profits) money and we [shops] could focus on trading goods. Now we pay for everything!

This remark was made pertaining to the (increase in) surcharges payable by merchants accepting credit card payments. The costs of spending/accepting money are - contrary to what one might expect with economies of scale and the advances in technology – going up and shops now face a surcharge in the range from 1 - 6% depending upon the credit card in question, and choice of payment processor.

Could we do better? Heck yeah!

With the obiquitous smartphone and it's NFC (near-field-communication) a modestly complicated app could provide the interface and a simple request could shovel funds from your account to that of the shop keeper. Important to notice – this is how it is done today, for all in Denmark, but with the "added help" of several parties sucking that tit! The basic transaction is

1. verify that buyer's account is valid and has funds
2. verify that seller's account is valid and may accept funds
3. move funds from the buyer to the seller

Whatever is wrapped around this simple 1 computer operation is value adding – at the expense of the users!

Peering down the nuclear catastophe abyss I posit this is indeed national critical infrastructure not far from energy distribution, and miles ahead of current national hallmarks like museums, (rail)roads, schools, hospitals, more.

You may ask: but 1-6% isn't going to rock any boat now is it? Well, that depends upon your definition of boat, and rock! The EU reported on non-cash payments in 2023 being at EUR 111+ trillion - even 1% would slice a decent trillion (that is a million millions) euro off of consumers and businesses budgets! The basic "service" – moving money from one account into another - could be handled easily by 1 computer/million users which translates into some 600 in the entire EU and keeping them afoot would not set back the ECB more than 1/100* of its 2023 operational costs which were EUR 1,200+ million.

Real estate

The final brick - pun intended - to the puzzle comes with a disruption of real estate, and not just real estate as in land, brick and mortar but consumer durables like cars, boats, houses, dish-washers, more.

With the current consumption scheme that does not compute at all provided the climate issues facing all of us, we have to build better/longer lasting durables and develop a more fine-grained logistics system for redeployment of used goods.

Connecting every durable to the aforementioned pigeon tokens network will allow any buyer to perusing the event logs of any durable and - perhaps with the help of professionals - gauge a fair price. Event logs could be attached to subscription models and provide governments with models for taxing less performing durables. The possibilities are endless –  

To sum it up a recent study shows that the finance sector sits uncontested in the top when considering 128 industries/sectors when comparing the wage premium/rent sharing which is an indicator of less than optimal competition and market inequalities.

*) establishing and programming this pigeon token network would require some funds but sidestepping the urge to complicate and - cut to the chase - so to speak building a v1.0 of the pigeon token network would ask for less than EUR 5 million. Propagating it across the EU zone would be effortless with the primary "sellers" being shop keepers promoting this 'cheap' system to consumers and perhaps offering rebates when utilised.

At 10-15 locations across EU with compute costs ranging from 3 - 50 EUR/month a 600 computers strong system (4-6 in each location – with perhaps 3-5 main locations and 5-10 secondaries for spikes and failover) would accrue less than EUR 50,000/month whereas  operational staff and engineers when out-sourced might cost EUR 100,000/month – a total of some EUR 2 million/year. Add another EUR 2 million/year for separation of trafic, and allow management and further "complications" vis-a-vis standard EU bureaucracy and other leeches meddling with a resulting 3x factor will bring the costs to some EUR 12 million/year.

Den seneste tid har budt på en veritabel bredside i medierne, med dem selv som afsendere, oftest den (påtagede) indignerede, krænkede, part eller i det mindste som den måbende voyeur. Politikerne har ikke været sene til at stable deres holdninger op på de traditionelle kasser af velmenende løfter og (mestendels tomme) trusler mod tech-giganterne –

Så hvad er op og ned i det?

Når medierne og politikerne, og resten af os for den sags skyld, skriger på at nogen bør gør noget, er det sådan set ikke forkert! Det kan næppe være sundt for unge, mange langt fra kønsmodne, at se porno i timevis; det er uvist om det overhovedet er "sundt" for voksne, så her tænker jeg, at jeg er dækket rimeligt ind!

Det er løsningen, der er helt løsrevet fra virkeligheden! Jeg skal prøve at forenkle det efter bedste evne:

Hovedparten af indholdet på Internettet leveres af web-servere, der måske kan sammenlignes med bibliotekarer. Du går til skranken og spørger efter en bog titel. En yderst tjenestevillig bibliotekar springer fluks ud bagved og dukker 2-300ms senere op igen, bærende på den ønskede bog, som du derefter slænger dig i en af de dertil opstillede sækkestole. Du har ikke lånt bogen endnu - kigger bare i den - og bibliotekaren kan måske i bedste fald huske bagefter, at du da vist havde mellemblondt år.

Nu kommer "bog politiet" så og forkynder for alle læsehestene, at bøger om heste for fremtiden kun kan lånes af rødhårede. 1-0 til kontrollanterne.

"Jeg kan ikke lade dig se i den bog", siger bibliotekaren strengt, og peger på dine umiskendeligt mellemblonde hårtotter, der titter frem under huen. Du foretager et planmæssigt tilbagetog og regrupperer i ly af SjovHat butikken, der på det seneste har fået vældigt gang i salget af røde parykker.

1-1

Nu skal alle boglånere herefter kunne fremvise gyldigt ID. 2-1 til kontrollanterne.

"Jeg skal bede om ID før du kan komme ind på biblioteket" konstaterer vagten ved døren bryskt, da du tager trappen i 2 spring. Kørekortet fra Legoland køber hun ikke, men din storesøsters sundhedskort virker straks meget bedre.

2-2

Nu skal jeg ikke trætte med et utal af tænkte scenarier fra det lokale bibliotek, blot konstatere at hvis det eksempelvis ikke er lykkedes (endnu) at komme salget af alkohol til mindreårige til livs, er chancerne for at de elektroniske ækvivalenter bliver løst, nok mildt sagt til at overskue!

- fordi flere forhold spiller ind, som ingen har den fulde kontrol over – end ikke et så gennemkontrolleret land som Kina!

1. Afsenderen af en forespørgsel - på for eksempel at få vist forsiden til en hjemmeside, der har samlet dødsvold videoer fra hele verden - har ingen forbindelse til udstyret, og afsenderens brug af udstyret har ingen konsekvens for afsenderen. Afsenderen kunne for den sags skyld stå og pege på en helt uskyldig tredjemand med en pistol, og forlange at vedkommende kommanderer udstyret.
2. Udstyret/maskinen sender forespørgslen i små bidder der hver især kan sammenlignes med vanddråber, der løber ned over en rude. De kan tage forskellige retninger under vejs, men ender alle på drypnæsen under vinduet. Én af grundene, til at Internettet er blevet så populært, er at denne 'rude' er så fleksibel, at hvis der sætter sig noget skidt midt på ruden, glider vand dråberne blot udenom - de skal nok komme frem. På samme vis når forespørgslen bliver besvaret; her er det blot endnu mere udtalt fordi der er tale om mange flere små bidder (typisk). I dag er det muligt at koble sig til Internet på rigtig mange måder (radio, fiber, mobil, måske endda stadig gammeldags telefonlinjer).
3. De små vand dråber - den enkelte "pakke" af data - kan gemme sig i andre dråber, så det bliver meget svært at "filtrere" en bestemt slags dråber ud (omend jeg for fuldstændighedens skyld skal indrømme at Kina har haft en vis succes med at gøre det).

Så - er svaret så, at vi ikke kan gøre noget?

Nej - langt fra - men som i eksemplet fra biblioteket, vil det kræve en fundamental ændring af synet på Internet, og på begrebet kontrol, når vi kommer ud i den anden ende. Ændringer som de fleste nok ikke vil bryde sig om.

Før vi kan ændre noget bør vi imidlertid først betragte 'systemet' og identificere dets vigtigste karakteristika:

• kontrol
• den frie aftaleret
• bytteforhold
• tillid

Kontrol: Vi efterlader masser af "spor" når vi som forbrugere surfer Internettet i vores jagt på oplysning, underholdning, tilbud, kærester, osv. Så mange spor at man i EU er blevet enige om at rejse en pegefinger. Det er sådan set også fornuftigt, og måske kan det give lidt mere plads i reklamebudgetterne til den trykte presse, radio, TV, og andre medier, som har henslæbt sig gennem en Sahara lignende tilstand siden især Google og Facebook satte opsamlingen af spor i system.

Nu vil vi så gerne rulle noget af denne "anonymisering" tilbage, så tech branchen kan sikre os mod - os selv - og naturligvis overrække nøglerne til denne kontrol, til politikerne, som jo ved, hvad der er bedst for os; eller i hvertfald for "the greater good"!

Men, som vi gennemgik i eksemplet fra biblioteket ovenfor, er kontrol på Internettet en monumental og samtidig uregerlig og diffus størrelse, der stiller flere spørgsmål, end den giver svar: flertallets diktatur? bonus pater in familias? Laveste fællesnævner? Pareto?

Den frie aftaleret er hjørnestenen i interaktionen mellem mennesker. Den sætter os i stand til at købe en grill i Bygma, også selv om den samme grill i et andet byggemarked koster 500 kr mindre! Tidligere gav det plads til langt flere led i varekæden - fra grill'ens fødested til forbrugerens terrasse. Her har Internettet kollapset varekæden i sådan en grad at det "næsten" er muligt at købe en bil på nettet - fra fabrikken, hvor de bliver fremstillet!

Det har også givet plads til en ny slags "kræmmere" som fik frataget deres levebrød på markedet, hvor de købte billigt i den ene ende, og spurtede ned i den anden ende, og solgte med gevinst. Nu lever de af at sætte webshops op, hvor de sælger varer "i den ene ende af markedet" (fx i Danmark), som de så bagefter spurter "over i den anden ende af markedet" (fx i Kina) og køber med gevinst. Bortset fra rækkefølgen, er metoden præcis den samme.

Bytteforhold er en (anden) vigtig brik i billedet. For at forstå mekanikken, som regerer Internettet, kræver det at vi ser på det stik modsatte!

Fortæring af en flødeskumskage og medfølgende nedsvælgning af den obligatoriske kop skoldhed chokolade - RIGTIG chokolade. Du betaler (egnsbestemt ganske vidst) en mindre herregård for arrangementet, og retten til at sidde og blomstre i dekorative omgivelser indtil der gror hård hud på -

Konditoriet har den udfordring, at det ikke kan sælge flere kage/chokolade combo'er end de 1) kan nå at fremstille, 2) har stole og borde til, 3) kan mase kunder igennem butikken til, hvis de kan overbevise 'tåberne' om at slæbe kolesterol giften med sig hjem, men selv hvis de løser alle de udfordringer, med et hav af bagere, udvidelser af konditoriet til Field'sk dimensioner, og ja, hvem ved hvordan de får nogen til at tage varm kakao med sig hjem i et papkrus – selv da er der en fysisk begrænsning på hvorlangt fra, kunderne vil køre for at sidde og spise - eller tage med hjem - flødeskumskager; trods alt!

Internettets kundeunderlag er principielt alle mennesker på hele jorden - selv dem uden Internet forbindelse, for de kunne jo sådan set godt få lyst til et eller andet, og kortvarigt benytte en vens forbindelse.

Konditoriet skal betale alle og deres fætter, hvis det vil udvide forretningen. Kommer der mere trafik til en hjemmeside kan det i nogen tilfælde betyde at indehaverne kan forhandle sig til en billigere pris pr trafik enhed.

Så meget på hovedet vender alt! Hvad der i "den virkelige verden" ville kræve megen forberedelse, lang tid til implementering og realisering, og betydelige økonomiske risici, kan i "den elektroniske verden" ofte løses næsten øjeblikket, og med betydelige omkostningsfordele som resultat. Forretningsmodeller skalerer bare bedre på Internettet.

Tillid har været en effektiv filter mekanisme i måske årtusinder. Længe før Gutenberg udvekslede mennesker information, men båndbredden var horibel ringe og fastholdelsen ligeså. Natur/menneskeskabte katastrofer kunne bort erodere stort set al viden på kort tid - som fx da biblioteket i Alexandria brændte (uanset at der er tvivl om hvormeget viden der reelt gik tabt). Information var - også dengang - flygtig og bundet meget hårdt op på tillid til afsenderen. Den har aldrig været perfekt, men tidligere var det trods alt nemmere at kunne se en person i øjnene og, i det omfang modtageren besad menneskekendskab (og dermed i et vist omfang kunne filtrere afsenderens løgne), validere kvaliteten af den leverede information.

Internettet har på den ene side frarøvet den enkelte modtager dette værktøj omend samtidig leveret et andet: muligheden for at søge alternative kilder hurtigt, enkelt og billigt (egenskaber som tidligere ikke var for hånden). Problemet med mennesker er imidlertid at de er dovne, og så vil de i grunden gerne tro godt om deres medmennesker, til det punkt, hvor de direkte bliver løjet til. Så i stedet for at forholde sig kritisk til en information, vælger mange at acceptere kvaliteten af denne information, og udsagnet som sandhed. Fejlen ligger hos denne, den første modtager, men vokser eksponentielt, ja mere logaritmisk, når informationen bæres videre til modtagerens inderste tillidskreds! Historien om fjeren og de fem høns som anskuelsesundervisning på daglig basis.

Når forskere og studerende ved de højere læreanstalter fremstiller rapporter og samler deres undren, indsigt, og erkendelse, forventes/skal de vedlægge kildehenvisninger, der dybest set er der, for at kunne skabe den nødvendige tillid hos en læser.

Hvad kan vi så gøre?

Vi starter bagfra i listen – fordi det, måske, løser flere af de andre udfordringer! Vi starter med at genetablere tilliden; tilliden mellem afsender og modtager. Det behøver ikke nødvendigvis være en fordel, i det mindste ikke for afsenderen, der med den her model risikerer at stå uden et produkt, uden en fordel, et spiel – og dermed uden en interesse i at deltage (og ja - det vil så være et problem i sig selv, som vi må arbejde med).

Kan vi ikke "bare" forlange at alle afsendere skal bruge MitID? Teoretisk set jo - hvis MitID var et fantastisk produkt - men det er det ikke, og der er så mange use cases hvor MitID ikke virker i dag, blot i Danmark, at det vil være en meget lang og meget sej kamp op ad bakke, at løse det. Lad mig nævne 3: unge/børn under 13, ældre/fysisk udfordrede/hospitaliserede immobile, maskiner. Dernæst kræver MitID en infrastruktur, som vi har i Danmark, men som langt fra vil være tilstede i resten af verden. Endelig er transaktionshastigheden håbløs; forestil dig at skulle bruge MitID i supermarkedet eller på togstationen.

Hvad er kravene da?

Hastighed

For at begynde bagfra (igen) er målet at den samlede transaktionsvarighed ikke må være over 7-800ms, altså lige under et sekund. Det er vigtigt, fordi vi mennesker har en "pause" oplevelse, der ligger omkring et sekund. Alt under 1 sekund sker "med det samme" – alt over 1 sekund "hænger".

Infrastruktur

Dernæst er kravet til infrastrukturen at mindst én af brugerne – enten afsender eller modtager – har Internet forbindelse i transaktionsøjeblikket, og at begge parter enten har haft eller får forbindelse indenfor et kort(ere) tidsrum. Der vil være (mange) situationer, hvor dette krav vil være svært at opfylde - det er jeg klar over - men mange af de situationer mener jeg bør kunne løses ved at ændre spillereglerne for informationsudveksling i transaktionsøjeblikket.

Minimum af interaktion

For at løse den værste forudsætning skal vi selv medbringe tillid; tillid til maskinen! I det mindste i et afmålt omfang. Vi skal reducere den menneskelige interaktion med maskinerne, og lade maskinerne selv træffe afgørelserne – og så naturligvis giver brugerne en veto-ret. Retten til at sige maskinerne imod, til at afvise en transaktion, som maskinerne ellers er blevet enige om er ok.

Hvordan - sådan mere i praksis?

Overlader vi etableringen af tillid til maskiner, kræver det først og fremmest at maskinerne er gennemskuelige - så vi forstår dem - og dernæst at mennesker eller organisationer, som vi, som individder, har tillid til, er i stand til at verificere at maskinerne virker, og til stadighed har mulighed for at gentage denne verificering. Det vil sige: vi har brug for et uafhængigt organ, valgt af forbrugerne selv, tillagt den fornødne kompetance, og ansvar, for at efterprøve og til rutinemæssigt/periodisk tilse maskinernes korrekte virke.

Maskinerne er, ladt alene, ikke-korrumperbare, og derfor bør der ikke være nogen mulighed for at "komme til dem" – ud over altså i forbindelse med det uafhængige organs revision og kontrol af maskinernes funktionsdygtighed. Det er ikke umiddelbart nogen uoverstigelig hindring. Vi har titusindvis af automatiske maskiner i drift over hele kloden, som døgnet rundt dirigerer telefon trafikken, Internet trafikken, energi og andre kritiske systemer. Vort teknologiske niveau er også sådan at de er overskuelige at bygge - det er ikke raketvidenskab, og derfor ikke nogen voldsom investering.

Det var sådan i store træk alt det positive! For i det følgende kommer så en række af de praktiske tiltag, og deres "negative" konsekvenser. Negative har jeg sat i anførselstegn, fordi det negative afhænger af øjnene, der ser. Der findes mig bekendt ikke mange beslutninger i livet, som ikke har konsekvenser - store eller små. Nogle konsekvenser kommer du selv til at døje med, andre bliver det op til dine børn at overkomme eller forlige sig med. Andre igen påfører dine omgivelser konsekvenser, måske i form af ændrede/forringede/tabte forretningsmuligheder.

Det afgørende her er ikke konsekvensernes størrelse eller omfang, men om vi som mennesker/samfund/civilisation vurderer dem som acceptable 'omkostninger' for at opnå en række fordele. Jeg ville ønske at det var beslutninger, vi kunne overlade til politikerne (og så i bedste mandagstræner stil hade og nedgøre bagefter) men det kan vi ikke, fordi politikerne aldrig ville turde træffe beslutninger, der potentielt ville gøre dem selv overflødige, samtidig med at betydelige industrier ville visne væk; industrier der traditionelt har levet et symbiotisk liv med statsmagten. Hvem og i hvilket omfang kommer vi til!

Revisionssporet er et kendt kunstgreb fra økonomiens verden. Man kan kalde det en sladrehank, men det er upræcist, for revisionssporet angiver ikke nogen, og sladrer ikke om nogen. Her er for eksempel Skat's definition af begrebet:

Bogføringsloven kræver, at der skal være et fyldestgørende revisionsspor så alle indberetninger kan spores tilbage til den nødvendige dokumentation (grundbilag), fx låneaftale og til den indberetningspligtiges regnskab.

Det er med andre ord en identifikation/en registrering af en hændelse. Det er en kilde til mange omkostninger, meget arbejde, og megen interesse i alle typer virksomhed, offentlige såvel som private, fordi: der skal være styr på økonomien.

Inddrager vi dette revisionsspor i hele vort liv, får det selvsagt en kolossal betydning og uoverskuelige konsekvenser. Før du forkaster idéen vil jeg bede dig gøre et lille tanke eksperiment: hvis alle de mennesker, du har været i berøring med igennem hele dit liv, enten direkte eller igennem dit arbejde, som kunde eller leverandør, igennem din rolle som barn eller forælder - hvis de alle kunne samles i et rum, og få lov at tale sammen indbyrdes? Hvordan ville det påvirke din opførsel, dine beslutninger, din moral/etik? Stadig et nej - ikke? Så spørg dig selv, hvordan alle dem, der i tankeeksperimentet er samlet i rummet, ville svare!

Hvordan skal vi i praksis kunne koble et revisionsspor på vort liv? Det kan vi gøre ved at anvende en teknologi, som benyttes i en helt anden sammenhæng: blockchain teknologien, benævnes den. For krypto valutaer er den altafgørende, og for krypto valutaernes ukronede konge, bitcoin, hele fundamentet. Langt den overvejende del af krypto valutaer eksisterer i et slags ureguleret parallel univers, hvor den enkelte valutas værdi (for de flestes vedkommende) er bundet på værdien af bitcoin eller afhænger af brugernes tillid. Blockchain er meget kort resumeret, en elektronisk analog til en perlekrans med en knude bundet om en perle for hver registreret transaktion (hvor transaktion kan være alt fra et kærestebrev til en embedsmands randbemærkning under sagsbehandlingen i Finansministeriet). Fordelen ved denne perlekrans er at hver transaktion kan følges – og benytter vi den overalt, også i virksomhederne og deres bogføring, får begrebet dobbeltbogføring pludselig en helt anden og endnu mere genial betydning.

Virksomheder bruger, som alerede nævnt, en del energi på at sikre et korrekt revisionsspor, men problemet er at sælger og køber virksomheder (når de handler med hinanden) har hver deres revissionsspor. Isoleret set kan det naturligvis være en fordel (for en konkret virksomhed), fordi den kan tilpasse sit revisionsspor til sit aktuelle behov (det er meget ofte en omgåelse af reglerne, men desværre ikke nogen påstand - Enron, WireCard, Nordisk Fjer og IT Factory er blot nogle af de mere prominente eksempler), men med en perlekrans, hvor transaktionerne med en køber eller en sælger skal passe sammen, forsvinder denne type fuks med et slag. Det samme gør sig naturligvis gældende, når køber eller sælger er en privat person.

Det fjerner også bankernes behov for at grave efter hvidvaskningsforsøg – forsøgene vil sikkert ikke forsvinde, men de vil meget enklere at efterprøve.

Vi kan også benytte perlekransen i en anden sammenhæng. Når forældre giver deres børn elektronisk udstyr som computere, smartphones, og smartwatches, bør de tilbydes en mulighed for at installere programmer, der anvender denne perlekrans teknologi. Det gælder sådan set også de devices voksne selv anvender.

Fravælger forældrene det, for det bør naturligvis være et valg, fraskriver de sig muligheden for at placere skylden på tech-giganterne, sådan som det sker i dag.

Hvorfor? Fordi det med perlekransen (eller rettere, med de programmer som benytter denne teknologi) vil være muligt at benytte en positiv liste af tjenester, ligesom det også vil være muligt at spore brugen af den enkelte tjeneste, hvilke data der er blevet udvekslet, og med hvem.

Der er endnu et anvendelsesområde – penge. Benytter vi perlekransen på udvekslingen af penge, fjerner vi begrebet penge lugter ikke, fordi det herefter vil være muligt at følge enhver transaktion - følge brugen af hver enkelt 25 øre. Det vil have en række afledte effekter, som jeg vil behandle i en særskilt post. Det vil være måske den mest samfunds- og system omkalfatrende ændring, mange gange større end da Danmark indførte danKortet.

Det sidste område jeg vil nævne, hvor vi kan bruge perlekrans teknologien, er valg. Når enhver transaktion kan spores og valideres, vil det være nærliggende at benytte teknologien til at afvikle elektroniske valg. Valg kan afvikles flere gange om dagen om nødvendigt, og prisen vil være negligerbar. Det kan være valg til bestyrelser, foreninger, kommunale, regionale, statslige. Valg i grundejerforeningen og valg til Folketinget. Ja - det kan over tid blive nødvendigt at skrive Grundloven om, for hvis alle kan stemme altid, bliver Folketinget mere en administrativ funktion, der forbereder borgernes valg (ud fra forslag de selv har stillet) og debatterer dem (på borgernes vegne) i transmitterede sessioner, med det formål at klæde den enkelte borger på, til at kunne træffe sit eget valg, på et veloplyst grundlag.

This is the third post evolving around the trust issues facing most facets of using the services offered by the cloud. I've questioned the need for trusting content and I've sketched a decentralized authentication protocol. Now we must turn our attention to the real reason for jumping through all these hoops: the content – the message.

I guess most of you have played the game that goes a little like this: get lined up in a row with 4-7 people in each row, and have the first person in each row have a pen and a piece of paper, and let each of the rest of the people in each row stand close enough to their peer in front of them to reach their back. Now draw a simple figure on the back of the person at the back of each row, and have each person draw this figure on the back of the person in front of them, until the figure reaches the person in the front of each row. Finally have the first-in-row people draw the figure on paper. Chances are that 1 in every 10 rows get it fairly right.

Quite an introduction to signal/noise in messages, right? That's even without introducing any external sources like lack of light, high volume playing of music, more.

Keeping messages safe traveling from the sender to the receiver is quite a feat, hence any message should be verified against a hash calculated just as it leaves the sender.

So in order to allow for secure transmission of trustworthy messages what do we have?

1. We must allow for full transparency pertaining to the compilation of the message in effect allowing the receiver to reach at the same "conclusion" as the sender did once finished compiling the message.
2. We must allow the receiver to question whether the message is exactly as intended by the sender.
3. Finally we must cater for the paranoia of the receiver – allow for them to ascertain themselves of the authenticity of the sender.

We've dealt with Number 3 in a previous post.

Number two could be dealt with rather mundanely using a simple hash. The sender will have to keep this hash readily available at all time (they will probably 'outsource' the job to some machine for receivers (machines) to question on a allways-on-schedule).

Number 1 is a totally different animal! Current levels of technology offer many facets of this transparency but in order to be practical in operations these technologies will have to be bundled in novel ways. I'm not able to detail this toolset in proper details but I will disclose a few glimpses as best I can:

Written content may prove the easy one. When starting on a new message (whether a SMS or the next War & Peace) the author will initialize a repository for persisting every small change, and then every few hundred milli seconds the workbench/editor will autosave the deltas (changes) to the document(s) together with occasional biometrics from the author and other environmental variables like what the time in the current time zone is, current air pressure, temperature, more.

I see your next question forming as you read! Is the really necessary? Not for persisting a groceries list certainly not but I guess neither you nor I will be the best judges of that - the receiver will.

I like to think that any sender will lean towards placing as many pieces of verifiable facts as possible in the hands of the receiver when they face that terrible situation: Is this in fact a trustworthy message.

All of this obviously builds on a presumption that the sender/author does indeed compile their message in good will, fact founded, and as a bonus pater familias. I am well aware that such a precondition is not by a long shot the standard operated by many authors – recent years have witnessed political movements like trumpism trumpet (pun intended) its alternate reality facts without remorse and demonstrating a rather dinged morale at best. The model I'm pedaling will none the less operate just at well in any reality. It only takes receivers to acknowledge and trust the sender; and if they get verification that the sender is indeed who they claim to be then by their standards the message will be trustworthy (in their reality).

Any content, any message, clearly will grow in size depending on the number of variables allowed by the sender/author. Battling this issue will add to the exchange protocol between sender and receiver. Receivers may instruct machines to initially ask only of the sender machine the content and then only when instructed they will start asking for meta data.

So far I've applied only the DNS protocol and the HTTPS protocol and retrieving the message/content could easily utilise the HTTPS protocol as well with one caveat: HTTPS is a stateless protocol and in a fully decentralized state where each sender keeps all machines on their own device it may prove a more convoluted endeavour to facilitate the workflow contrary to one where most of the machines are operated out of 'fixed locations'. Allow me to elaborate.

Senders operating out of their device while roving will change network address frequently. That does not prove a problem by itself as dynamic DNS may update the conversion from ATHLETE69 to some IP address in a few milli seconds – but moving between various networks with a host of different firewalls could trouble the questioning, and requests for transmission depending upon the ports allowed inbound to a network; and port 80/443 which are used by HTTP/S are seldomly open from the outside inwards, only inside outwards, or they are directed at specific local area network addresses in a DMZ, because the network has web servers placed here. It's not like undoable only it will require some careful consideration. Optimally all senders would decide for hosting-provider services to complete tasks commanded by the sender's machines but such luxury will severely narrow the total addressable market! One prominent way of overcoming ports not being available, also categorized as networks not being traverseable, is adding something called TURN servers (short for Traversal Using Relays around NAT). This, however, adds considerable system complexity to the overall design. Another design choice would be store/forward where messages are kept in escrow until users' machines are able to collect - much like email operates. Not a flexible choice either. Then there is the appliance model.

From a privacy policy point the appliance model is perfect. From a system design point of view even so. Considering the user experience most certainly too. You could say: it just works - to quote Steve Jobs back in 2011 when introducing iCloud.

When signing up for a pigeon token the user will receive a small appliance perhaps the size of a packet of cigarettes chewing gum that they will attach to their home network.

This obviously will only work if you actually have got an Internet connection at home (some 70% in EU, about 97% in the US, and 60+% globally as of 2023). The appliance will host the data store and other machines like the certificate authority perhaps even if the user may prefer and buy third-party service providers for other reasons. Now the store/forward design suddenly sits a lot more comfortable with me.

Senders may leave notices with the 'user' / receiver with out them even have their device turned on, without any privacy issues coming into play. The user may choose to let machines do the verification and message transmission fully detached from their own device and in timeslots (eg when the user is sleeping) not disturbing the user. Roving with their device the user will 'call home' at intervals or choose to stay connected and operate a TURN server themselves. Options will be available. And, importantly, the aforementioned alternatives still are viable – it's entirely up to the consumer/user and their desire for privacy, security, comfort, ease of application.

In a post the other day I posited that by "..add[ing] a distillation of DNS with scents of SSL and Certification Authorities.." we can manage the trust issues currently wreaking havoc amongst "cloud" based services. With this post my intention is to clarify WTF I was rambling about 😅

But first – a fair warning 'cause this post gets pretty detailed about the tech. In more layman's terms you could describe it something like this: In order to call Ms. Someone I'll go get a phonebook (or more recently, an online listing site like YellowPages) and start searching for Ms. Someone. I'll end up with a set of digits (because that was how the signaling of the callee's handset/phone is converted from man-readable to machine-understandable) and dialing the sequence will - hopefully - connect me with Ms. Someone. Unless I block the Caller ID (hide my phone number) Ms. Someone will at least learn my phone number. If we are not acquainted all she will have to go by is looking up my number in the inverted listing (ie instead of a name, she will be looking for a name by the number displayed on her handset. Provided the listing service is to be trusted and I'm listed she will learn my name and possibly a postal address.

Quite a number of Internet services rely on DNS which is short for Domain Naming System. It's a fairly simple protocol not too far from the above example. Got a name - get a number. Got a number - get a name. We can utilise this to allow machines looking up the identification of senders merely by providing a sequence of digits. Entertain me on this: in order to allow at least 1 specific number to all humans on Earth we'll need at least 11 digits (99,999,999,999 possible 'addresses')  at the moment – we might get away with 10 digits for a while but.. Now let's add some machines and like devices of various sorts and we are looking at perhaps 12 or 13 digits. Throw into that mix the commercialization of this 'tag' – and we end up with something like

WD13CHM4NN

It's short enough for you to remember and not too complex to share. At least it's quite an improvement over john.doe1234@someone.somewhere even if you should end up at the short end of the stick so to say, with something like W3KJ98DF1. Businesses might fight over C0C4C0L4 and N1K3  –  I like to think that they absolutely should! Offering the token on a first come first served term will allow for trade and drive adaptation.

10 characters is no coincidence - with 25 letters and 10 digits there will be 36 (if we allow for 'space', ie not filling in every position) to the 10th power affording an incredible 3,656,158,440,062,976 "addresses" leaving well above a staggering 350,000 addresses for each of the first 10 billion people on Earth.

DNS operates on a particular tree like structure of name servers scattered all over the globe with a fairly small number of root servers each holding references to a very large number of domain regional name servers that in turn are responsible for referencing authoritative nameservers each being able to do the name to address conversition for a particular domain like say https://jp.dk. This design affords any machine to having an answer to a simple question in as little as 1 request (if the resolver have the answer cached) or more often, 4 requests, usually in a time range of 50ms - 150ms. The question goes somewhat like this: where should I turn to talk to www.adidas.de? In exactly the same way DNS could be operated to answer another kind of question: Who can tell me where to ask questions regarding B3ATL35

I posit that the DNS protocol be amended allowing machines to receive two pieces of information: an IP address and a public key, and with that information they may request an authentication package using the HTTPS protocol like this

GET https://192.168.1.100/authp

The authentication package would come in two layers of encryption; the protocol based TLS/SSL encryption and inside that, the private/public key encryption which the machine putting forward the question in the first place would use the aforementioned public key to decrypt.

In a totally decentralized state every 'user' would carry their own authentication package on their own device but catering for fault tolerance most likely will require persisting the packages in alternate places in the cloud too, albeit still under the command of the owner of the authentication package.

It might all look something like this (keeping in mind that all 'swim lanes' might be physically running on one device – if the receiver merely is another process; this obviously is what might be considered an edge case though):

As a person with a desire to send messages to others I would go to a certification authority (in person) and submit my biometrics (photo, spit, iris scan, gait, more) to a machine operated by this authority. My device would share a public key for the authority to use in the proces of compiling my authenticatin package.

The chain of command of these certification authorities (CA) is very important as receivers would have to rely on the CA's not being compromised – ie corrupted to collecting false biometrics. It will most probably require a separate protocol to be operated in the open source community and disseminated amongst users (senders and receivers) collecting and verifying biometrics from their peers regularly, thus reporting what they see. Any discrepancies would demote CA's and ultimately close them down if no one trust them to collect and compile biometrics in an orderly manner. One could theorize on the application of "phonebooth" certification authorities operated entirely by machines and completely detached from any networks given the pure functional nature of their operation: provided the same input they will elicit the same output every single time.

Now with my encrypted biometric authentication package compiled for me and handed to me as the service provided to me by the CA, I will persist it on my device/machine and for safe keeping even place it in multiple alternate places in the cloud. I would not know, my self, what the package concists of - neither would the CA as they do not for privacy policy concerns persist any actual datasets pertaining to the transaction with me - except for a hash of the package handed to me along with a copy of the public key, for them to prove when questioned whether they did in fact compile my authentication package at all - no CCTV, facial recognition or any other recordings of me being there.

Depending on my temper and paranoia I will either add my device as the destination for questions regarding authentication or pick one of the alternate places in the cloud as the source of the truth. In any case I am now ready to start exchanging messages with receivers using this decentralized and yet highly centralized authentication system.

Regarding the DNS we are facing a few obsticles with the most important one being that the naming system is divided into something called TLD's (short for top level domains - like .com, .de, .es, and so on) and subsequent second level domains like exxon, maersk, and so on, effectively combining it to names like exxon.com, maersk.dk, etc.

Fitting the tokens/pigeons into this system can be done in a number of ways, one being attaching a bespoke TLD on to the tokens like WD13CHM4NN.tt, another being to add TXT records to a bespoke domain, fx pigeons.tt.

Catering for performance issues this particular 'domain' will receive a tremendous amount of trafic and as such probably be elevated to a particular root service - much like the f-root, but that's another story.

Content, generated by bots utilizing services provided by a seemingly endless list of LLM's (large language models) known by most as AI systems, most famous amongst them probably OpenAI / ChatGPT, ain't an issue –

What is, is whether the reader/listener/viewer is affected by the content or led to believe in an alternate reality! I'm careful here because reality is in the eye of the beholder! You could argue that not all realities are equal and be right but whether they are real is a much more questionable statement.

What separates content generated by living beings from content cooked up in slices of silicium is quickly becoming next to impossible to point to and that predicament may give rise to issues going forward – issues of a magnatude and consequence that mankind has not faced perhaps ever. This is "inventing fire" grade stuff!

Consider LLMs trained to voice your parents beliefs and teachings, and to be able to question them, discuss them, reason with them, and perhaps even make them reevaluate - decades after their passing! Or "machines" teaching you as an undergraduate!? How about "news servers" compiling ample "news" to keep you watching news reels for the better part of your life!? Systems providing you with 'guides' on what politician to vote for based on what you "like" and "believe" in.

Most of what I just listed are in fact not even science fiction - or at least it's quite doable if not in existence yet!

So the question begs: How do mankind somehow make a distinction between content generated by their peers and content generated by what ultimately are machines?

First we'll have to consider whether it is at all necessary for humans to be able to make such distinctions. Provided these 'machines' are driven by altruistic motivations you might argue that their outpourings will only help us survive on a planet increasingly worn out. But altruistic to whom? All of humanity or perhaps more narrowly - a small elite? Altruistic in the "for the greater good" kind of way? Machines with very discrete ends - like generating profits - most likely will not waive at the thought of decimating populations as some kind of collateral damage as long as they (the machines) are not actively killing people but merely consulting them on what to and what not to do - perhaps.

One of mankinds finest qualities, albeit one becoming rarer as of late, is the ability to weight for and against some decision, using their gathered experience, trained and acquired knowledge, ethical and moral codices, and 'gut feelings' – like when my grand dad would posit: Nå' skit kåme te ær' så wed'e et hwådden det wel wæ' (a danish dialect, I know, but basically 'rags to riches' meet 'old versus new money') meaning that you extrapolate trajectories of events and actions based upon paper thin samples from the past but because you carefully pick samples within context your gut-feeling will serve you right more often than not.

If every data bit is with out context and presented as fact! How are we to use our experience on that? Worse - if data bits are pedaled by centuries old honourable bodies firmly situated in the epicenter of humanity, like global newspaper brands and national television networks - then what? Do we question them - especially if what they offer seems to align with our beliefs and common sense?

Still with me? Okay, so next up is a brief setting of the stage: We have the Sender and the Message and finally the Receiver. What we are looking for is a way for the receiver to consider the message true and in fact offered by the sender and for the sender to actually having "put their best effort" into construing the message! That's the task like cut to the chase.

First, let's consider the Sender. Building trust usually meant delivering on your promises again and again. Skilled shoe-makers would come in demand when they time after time delivered wooden cloggs in pristine quality every time. By word of mouth people would agree: If you need the best quality in wooden cloggs - go to SomeNamedGuy. So we need some way of identifying the sender - like Yelp or TrustPilot.

Second, consider the Message. Lets go back to the wooden cloggs. Say one customer brings back their pair of cloggs only the next day after ordering them, and pass another customer doing exactly the same only to find that every single man and woman in town got a pair of cloggs in the span of 12 hours! You'd be right to wonder: is there something fishy about this? Can this shoe-maker really build that many pair of cloggs in one night? Compiling a trustworthy message will take time just as much as Avatar was not shot during lunch-break. But - I hear your question! Can big companies not produce more than perhaps a few pages of 'news' in a day? Certainly - but they consist of hundreds, perhaps thousands of employees each producing perhaps 1-2 pages every week. And people trust people/individuals - they do not trust companies. Why should they? You deal with Mr Anderson - not the entire Sales Department. So we need some way of verifying the build process of the message. A cross between versioning software systems like Git and the blockchain making every change immutable and set in stone for all eternity.

Finally, the Receiver. Our hitherto example lends not too well in this case. You see, the receiver may not even be human! Had they been we could ask of them to call the Sender and ask whether this or that piece of information was in fact of their doing or something compiled in a split second by some machine. The Sender could lie, of cause - and run the risk of being exposed and possibly never sell another piece of information. Now here we are in the mid 2020's and surrounded by machines - now what do we do?

We start by tying the build proces to a blockchain of sorts. It does not have to be the Blockchain running the entire crypto markets, any odd blockchain will do - as long as it is trustable. Being decentralized - practically in the eye of the beholder - should do! Providing content providers with a toolset that not only ties their product build process to a verifiable blockchain but allows them to commit work every minute/second/milli-second will be of paramount importance. Tying the build process to a blockchain that at the same time could offer a means to manage the consumption of this content holds some obvious promises by itself - but that is not really of interest in the scope of this post!

Now we are able to offer a ways for the receiver to verify the build process (and possibly the sources being used to compile the content). Now we need for the receiver to be able to verify the authenticity of the sender/creator. Is it indeed that well thought-off journalist freelancing for Le Monde or does it prove in the end that the content was compiled in more like micro seconds by utter transistors?

We add a distillation of DNS with scents of SSL and Certification Authorities effectively providing a body (with possible globally assigned assessor bodies constantly securing identities of creators) to persist and disseminate authenticities of senders, perusable by machines operated by receivers (which again could be other machines or real humans). Senders would have to travel to public offices or branch offices of this body to have their authenticity stored after offering samples of biometrics - fingerprints, sweat, iris scans, more. (See footnote for another angle on this body)

When the creator operates their workbench/editor/toolset - talking, typing, acting, whatever - they (could) allow the toolset to collect biometric data every so often, and hash these data into the same blockchain! In this way the product becomes an extension of the sender. Biometrics may of cause be falsified - and most certainly will be - but such cases will (like the lying Sender before) risk expose and condemnation. Allowing receivers close to senders collecting individual biometric samples will strengthen the entire workflow and system. With only a small sample of "true" biometrics collected by 1-2 fans close to their most-beloved actor, they could chip in to the entire system and build on the trust necessary for senders' authenticity to be verified.

I'll close this post by daring an example of this "tech":

 Melissa & Mustafa skipped their last class that day - word in the streams was that Hallifax had released a new ario that was crazy and they loved everything Hallifax  made; so much that a 1 hour lecture on DNA markers was a no-contest!

 Ready, Mel? Mustafa looked at her through the AR lense strapped to his head. She nooded. He pressed PLAY and they both lost their footing even though they were safely tucked in pillows and blankets on the floor - they knew what was in store for them! Wait! Melissa yelled and Mustafa pushed PAUSE.

 That's unreal! He couldn't possibly! Melissa nearly shouted still somewhat deafened from the first few second of the ario. She made a gesture and commanded: Show tracking from zero through 10 and the ario started again now stepping forward almost frame by frame meanwhile running verifications in a second window to the right of them and below the scene a line of check marks indicated that every frame was in fact not only genuine but had not received any after production editing except one frame. Melissa was not entirely convinced and continued: Show actors bio, she demanded. The scene froze and all 5 actors in the scene had small annotations labeled to their heads. One was a bot - the wolf - but the rest checked out. Cast credits below and another window above and to the left started listing time spent on set and commits ordered by the cameramen.

 I'll be da– Melissa studdered in disbelief. It was that good!

FOOTNOTE:

I mentioned a 'body' above – one to manage authenticities. This body could give way to a new dawn on the much hated "email" of yesterday. We could finally ditch the 'postbox' analogy. The analogy that has done so much harm for decades now!

 In stead of a completely anonymous slot, through which you as the sender is able to push whatever culpritous digital compilations for the poor receiver to have machines lingering anxiously over, spending millions if not billions of CPU cycles and endless watts of precious electricity trying to undo and rectify, you will now have a bullitin board for senders to pin their desire to forward messages (of any construct) to you, and in a few CPU cycles your assigned machine is able to verify the true identity of any sender and if deemed necessary by you go over the commits to the message easily discarding any suspicious looking fragments.

Phlex by Joel Drapper is some very clever Ruby code to componentizing your views, for all in Rails via the phlex-rails gem!

For what seems only like yesterday but probably is way more than a year I've kept adding components (what Rails labels partials I believe) to 'my tool-belt' building from this gem.

My goal was to be able to do

<%= render_form( resource: resource, 
    assoc: :participantable, 
    clipboard_prefix: (resource.new_record? ? 
      nil : 
      equipment_url(resource.assetable))) do |form| %> 

    <!-- 8< -- >
    <%= form.text_field( :name, 
      required: true, 
      focus: true, 
      placeholder: t(:name),
      input_css: "block w-full ...-300 rounded-md") %>

  <%= render_form_action_buttons 
    resource: resource, 
    delete_url: resource_url(), 
    deleteable: !resource.new_record? %>
    
<% end %>

To that end I started by handing the task to a helper

  def render_form(**attribs, &block)
    attribs[:action] ||= params[:action]
    render Views::Components::Form::Form.new **attribs, &block
  end

That prompted the erection of a module

module Views
  #
  # the form component is a wrapper for the form_with form helper
  # and it handles nested forms by adding an argument - assoc - to the initializer
  # another argument supports the clipboard prefix - copy/pasting of form field values
  #
  # Caveats: the form will not support deep nested forms - ie only one level of nesting!
  #
  class Components::Form::Form < Phlex::HTML
    include Phlex::Rails::Helpers::FormWith
    # include Phlex::Rails::Helpers::FieldsFor

    def initialize( **attribs, &block )
      @resource = attribs[:resource]
      @assoc = attribs[:assoc]
      @action = attribs[:action]
      @url = attribs[:url] || nil
      @clipboard_prefix = attribs[:clipboard_prefix]
      @classes = attribs[:css] || "scrollbar-hide h-full flex flex-col bg-white shadow-xl overflow-y-scroll "
      @screen_height = attribs[:screen_height] || "h-screen max-h-screen"
      @screen_width = attribs[:screen_width] || "w-screen max-w-md"
      @fields_css = attribs[:fields_css] || "border-b border-gray-900/10 pb-12 mb-14"
      @form_id = "form_#{Current.user.id rescue 0}"
    end

    def template(&)
      div( id: "#{@form_id}", class: "pointer-events-auto #{@screen_height} #{@screen_width}") do
        form_with( model: @resource, 
          url: set_url( helpers.resource_url()), 
          data: { form_sleeve_target: 'form' }, 
          html: { id: "#{@form_id}_innerform", enctype: "multipart/form-data", class: @classes }) do |form|
            hidden_field( :account_id, value: (Current.account.id rescue nil) ) unless %(account service).include? @resource.class.to_s.underscore
            unless @assoc.nil?
              hidden_field( "#{@assoc}_type", value: @resource.send(@assoc).class.to_s) 
              hidden_field( :id, assoc: @assoc, value: set_id ) 
            end
            div( 
              class:"flex-1 relative space-y-12",
              data_controller: "form",
              data_form_form_sleeve_outlet: "#form-sleeve",
              data_form_list_outlet: "#list",
              data_form_clipboard_prefix_value: @clipboard_prefix,
              data_action: "keydown->form#keydownHandler speicherMessage@window->form#handleMessages"
              ) do
                div( class: @fields_css) do
                  yield
                end
            end
          end
      end
    end

    def set_url helper_url
      u = if @url.nil?
        helper_url
      else
        @url
      end
      re = /(\/[0-9]*\/clonez)$/
      if u =~ re 
        u = u.gsub(re, "")
      end
      u
    end

    def set_id 
      return '' unless @action == 'edit'
      return @assoc.nil? ? @resource.id : @resource.send(@assoc).id
    end

    def boolean_slider_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::BooleanSliderField.new field, **attribs, &block
    end

    def checkbox_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::CheckboxField.new field, **attribs, &block
    end

    def combo_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      attribs[:elem_css] = attribs[:elem_css] || "space-y-1 z-10 px-4 sm:space-y-0 sm:grid sm:grid-cols-3 sm:gap-4 sm:px-6 sm:py-5"
      render Views::Components::Form::ComboField.new field, **attribs, &block
    end

    def datetime_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::DateTimeField.new field, **attribs, &block
    end

    def email_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::EmailField.new field, **attribs, &block
    end
    
    def file_upload_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::FileUploadField.new field, **attribs, &block
    end

    def hidden_field( field, **attribs)
      attribs[:resource] ||= @resource
      render Views::Components::Form::HiddenField.new field, **attribs
    end

    def number_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::NumberField.new field, **attribs, &block
    end

    def password_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::PasswordField.new field, **attribs, &block
    end

    def radio_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::RadioField.new field, **attribs, &block
    end

    def text_area(field, **attribs, &block)
      attribs[:resource] ||= @resource
      attribs[:elem_css] = attribs[:elem_css] || "space-y-1 px-4 sm:space-y-0 sm:grid sm:grid-cols-3 sm:gap-4 sm:px-6 sm:py-5"
      render Views::Components::Form::TextArea.new field, **attribs, &block
    end

    def text_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      attribs[:elem_css] = attribs[:elem_css] || "space-y-1 px-4 sm:space-y-0 sm:grid sm:grid-cols-3 sm:gap-4 sm:px-6 sm:py-5"
      render Views::Components::Form::TextField.new field, **attribs, &block
    end

    def token_field(field, **attribs, &block)
      attribs[:resource] ||= @resource
      render Views::Components::Form::TokenField.new field, **attribs, &block
    end

    def uris(field, **attribs, &block)
      attribs[:resource] ||= @resource
      attribs[:assoc] ||= @assoc
      render Views::Components::Form::Uris.new field, **attribs, &block
    end

  end
end

All of this really could've been unnecessary, had it not been for my unability to lure Phlex into accepting my nested forms in the `form_with`. As it turned out, though, I gained more than I probably lost in that battle.

In the form I render fields of all sorts. To that end I've constructed a rather monstrous generic_field.rb which most of my form elements inherits from. It looks somewhat like this [Disclaimer: there is most certainly no 'fiber rich meal' hidden here - only spaghetti I'm afraid]

module Views
  class Components::Form::GenericField < Phlex::HTML
    include Phlex::Rails::Helpers::Label

    # TODO: serious sanitization required!
    def initialize(field, **attribs, &block)
      @resource = attribs[:resource] || nil
      @assoc = attribs[:assoc] || nil
      @assoc_cls = @assoc.nil? ? 
        nil :
        @resource.send(@assoc).class.to_s.underscore
      @lookupClass = attribs[:lookup_class] || 
        (field.to_s.classify.constantize rescue false) || 
        @resource.class.to_s.underscore || 
        nil
        
      ---8<--- AHOALO 'stage setting' aka variables 
 
      type_s = @combo_type.to_s
      @is_single  = !(type_s =~ /single/).nil?
      @is_multi   = !@is_single
      @is_drop   = !(type_s =~ /drop/).nil?
      @is_list   = !(type_s =~ /list/).nil?
      @is_tags   = !(type_s =~ /tag/).nil?
      @is_search = !(type_s =~ /search/).nil?
      @is_add    = !(type_s =~ /add/).nil?
      @is_modal  = attribs[:modal] || false
      @showIcon  = attribs[:show_icon] || false
      @is_key_value = attribs[:key_value] || false

      @field_placeholder = attribs[:placeholder] || ''
      @elem_css = attribs[:elem_css] || 
        "space-y-1 px-4 sm:space-y-0 sm:grid sm:grid-cols-3 sm:gap-4 sm:px-6 sm:py-5"
      @label_css = attribs[:label_css] || 
        "block text-sm font-medium text-gray-900 sm:mt-px sm:pt-2"
      @input_css = attribs[:input_css] || 
        "block w-full shadow-sm sm:text-sm focus:ring-indigo-500 focus:border-indigo-500 border-gray-300 rounded-md"

    end

    def template(&)
      yield
    end

    def set_field_value **attribs
      values = (attribs[:value] || @obj.send(@field_name)) rescue nil
      return nil if values.nil? || 
        values == '' || 
        values == []
      @value_filter.nil? ? 
        values : 
        @value_filter.call( values, @items )
    end
    
    def set_display_value **attribs
      values = @values
      return '' if values.nil? || 
        values == '' || 
        values == []
      return @display_filter.call( values, @items) if !@display_filter.nil?     
      return values if (values.class.ancestors.include?( String) || 
        values.class.ancestors.include?( Numeric) || 
        values.class.ancestors.include?( TrueClass) ||
        values.class.ancestors.include?( FalseClass) )
      return values if values.class.ancestors.include?( ActiveSupport::TimeWithZone)
      [values].flatten.map{ |v| v[@item_label.to_sym] }.join(", ")
    end

    def label_for **attribs, &block 
      return unless @label_visible
      containercls = attribs[:container_class] || ""
      lblcls = attribs[:label_class] || @label_css
      fld = attribs[:field] || @field
      title = attribs[:title] || @title
      div( class: containercls ) do
        if block_given?
          label( @obj, fld, title, name: @field_input_name, class: lblcls, data: { action: "click->form#fieldFaq" }) do
            div( class: "text-sm text-gray-500" ) { @description } if @description.present?
            yield
          end
        else
          if( title =~ /translation missing/i)
            (title =~/<span/i) ? text( title ) : span( class: "translation_missing", title: title ) {fld.to_s}
            div( class: "text-sm text-gray-500" ) { @description } if @description.present?
          else
            label( @obj, fld, title, name: @field_input_name, class: lblcls, data: { action: "click->form#fieldFaq" })
            div( class: "text-sm text-gray-500" ) { @description } if @description.present?
          end
        end
      end
    end

    def values_for **attribs 
      values = nil
      return parent_values if @parent 
      return params_values( attribs[:values] ) if !attribs[:values].nil?
      return model_values if !@obj.nil? and @obj.respond_to? @field_name

      (@obj&.send("values_for_#{@field}") if @obj&.respond_to? "values_for_#{@field}") || []
    end    

    def parent_values
      begin
        return [{ id: @parent.id, cls: @parent.class.to_s, label: @parent.send(@lookup_label)}] if @parent
      rescue
        raise "Parent not found - or lookup_label wrong"
      end
    end

    def params_values values
      begin      
        case true
        when @field==:role && @resource.class==Role;                    set_role_values(values)
        when values.class.ancestors.include?( Integer);                 [{ id: values, cls: "", @item_label => "key" }]
        ---8<--- more cases
        else
          values
        end
      rescue
        raise "Parent not found - or lookup_label wrong"
      end
    end

    def set_role_values values
      values = "" if values.nil? || values.empty?
      values.chars.collect{ |v| set_item(v) }
    end

    def model_values
      begin
        return params_values @obj.send(@field) if @field != @field_name
        params_values @obj.send(@field_name)
      rescue
        raise "(generic_field) Model lookup failed - or lookup_label wrong"
        return nil
      end
    end

    def items_for **attribs
      items = attribs[:items] || []
      items.collect{|i| set_item(i)}
    end

    def set_item item 
      case true
      when item.class.ancestors.include?( String);                  i= (item.split(";").size < 2) ? ({ id: item, cls: item, @item_label => item }) : ({ id: item.split(";")[0], cls: item.split(";")[2], @item_label => item.split(";")[1] })
      ---8<--- more cases
      else
        i={ id: item[:id], cls: item[:cls], @item_label => item[@item_label] }
      end
      OpenStruct.new(i)
    end
        
  end
end

That leaves me with a fairly easy task when fx adding a component to display a password field:

module Views
  #
  # the password_field component is a wrapper for the password_field form input field helper
  #
  class Components::Form::PasswordField < Views::Components::Form::GenericField
    include Phlex::Rails::Helpers::PasswordField

    # arguments: field, assoc: nil, title: nil, data: {}, required: false, focus: false, disabled: false, 
    # text_css: "", label_css: "", input_css: ""
    def initialize( field, **attribs, &block )
      @url = attribs[:url] || ""
      super( field, **attribs, &block )

      @elem_css = "space-y-1 px-4 sm:space-y-0 sm:grid sm:grid-cols-3 sm:gap-4 sm:px-6 sm:py-5 #{attribs[:elem_css]}"
      @label_css = "block text-sm font-medium text-gray-900 sm:mt-px sm:pt-2 #{attribs[:label_css]}"
      @input_css = "block w-full shadow-sm sm:text-sm focus:ring-indigo-500 focus:border-indigo-500 border-gray-300 rounded-md #{attribs[:input_css]}}"
    end

    def template(&)
      div class: @elem_css do
        label_for
        div( class: "sm:col-span-2") do
          password_field( @obj, @field, 
            id: @field_input_id,
            name: @field_input_name,
            value: @field_value,
            disabled: @disabled,
            placeholder: @field_placeholder,
            autocomplete: @autocomplete,
            tabindex: @tabindex,
            required: @required, 
            data: @data,
            class: @input_css) do |f|
              yield
            end
          div( class:"text-sm text-red-800" ) { @obj.errors.where(@field).map( &:full_message).join( "og ") }
        end
      end
    end
  end
end

– and it brings back memories of `simple_form` when I get to do

<%= form.password_field :password, 
  autocomplete: "current-password", 
  required: true, 
  placeholder: t('password'),
  class: "appearance-none block w-full px-3 ..." %>

in my forms (knowning that it is all testable w/o any headless chrome, being 'just' PORO's, and promising to greedily suck out every last cycle the "cloud" may provide.

Life is sweat! Thank you Joel!

So - you've got this blog/website thing going, and you set it up using Ghost! And now you need to find yourself a new provider – and you cannot stop thinking whether you could do it all by yourself!?

Export all your content

Make a tarball of all your images - from content/images - in my case the path was /var/www/blog/content/images

Now follow this recipe

Import your content

'cd' into the proper 'content' folder and tar xf images.tar

That's how easy it is to move a Ghost based blog/website/thing

In my previous post I ended on kind of an "up key" with job done – which with hindsight probably was a bit exaggerated. I never got to mention Caleb Porzio who created AlpineJS.

app/views/accounts/_modal.html.haml is not ripe for generalization yet but this is what it looks like:

:coffeescript

  window.modalData = () ->
    {
      modalOpen: false,
      dispatcher: null,
      toggleModal: () ->
        @modalOpen = ! @modalOpen 
      initModal: (w,d) ->
        @dispatcher = d
        document.body.classList.add 'overflow-hidden'
        w 'modalOpen', (value) =>
          if (value == true)
            document.body.classList.add 'overflow-hidden'
          else
            document.body.classList.remove 'overflow-hidden'
      sendModal: () ->
        @modalOpen = ! @modalOpen
      openModal: (e) ->
        @dispatcher 'opened-event-modal',''
        @toggleModal()
        if e.detail!=''
          el = document.getElementById('account_modal_form')
          el.innerHTML = e.detail
          el.style.zIndex = '99'
      closeModal: () ->
        @dispatcher 'closed-event-modal',''
        @modalOpen = ! @modalOpen
    }

.fixed.inset-0.z-10.grid.place-content-center.justify-items-center{ :"x-data"=>"modalData()", :"x-init"=>"initModal($watch,$dispatch)", :"x-show"=>"modalOpen", :"@open-event-modal.window"=>"openModal", :"@close-event-modal.window"=>"closeModal()" }
  .absolute.inset-0.bg-black.opacity-10
  / %span.hidden.sm:inline-block.sm:align-middle.sm:h-screen( aria-hidden="true") ​
  #account_modal_form
    = render partial: "form", locals: { account: @account, header: t('.konto') }

The first (real) line of HTML beginning with .fixed.inset-0 holds these constructs:

:"x-data"=>"modalData()" – which scopes the reach of variables and methods to this DOM element and children

:"x-init"=>"initModal($watch,$dispatch)" – initializes scoped variables and if you need access to stuff like a dispatcher from your JS this is the proper place to announce it  

:"x-show"=>"modalOpen" – will show/hide this DOM element depending upon the truthiness of modalOpen

:"@open-event-modal.window"=>"openModal" – this is how eventListeners look like using AlpineJS.

:"@close-event-modal.window"=>"closeModal()" – label the event and attach .window and define what should happen.

With the modal sitting duck we just need a ways to call it up. I believe to have left off just about setting the rows right in my previous post, but I had to refactor that part (more will come, I anticipate):

.table-row.bg-white{"x-description" => "Odd row", id:  dom_id(account) }
  .table-cell.px-6.py-4.whitespace-nowrap.text-sm.cursor-pointer.font-medium.text-gray-900{ :"@click" => "openModal('#{edit_account_path(account)}')"}
    = account.name
  .hidden.lg:table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
    /= #link_to account.participant.name, 
  .hidden.md:table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
    = account.service_plan
  .hidden.sm:table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
    \-
  .table-cell.px-6.py-4.whitespace-nowrap.text-right.text-sm.font-medium
    = link_to 'Destroy', account, method: :delete, data: { confirm: 'Are you sure?' }

There's at least one more post after this one – this pattern begs a kind of componentization and my first target will be ViewComponents possibly married to Stimulus.

First, however, we will continue finishing the naive implementation with alpineJS, Turbo, and Hotwire. Check out the previous post if you'd like to see how I managed to get the 'new account'  working with a modal.

In the above code-block .table-cell.px-6.py-4.whitespace-nowrap.text-sm.cursor-pointer.font-medium.text-gray-900{ :"@click" => "openModal('#{edit_account_path(account)}')"} is about the only really interesting thing. It tells AlpineJs to go look for a method called openModal when the user clicks somewhere on the row.

I've put that – and a couple others – in the top of the view:

  :coffeescript 

    window.indexState = () ->
      {
        dispatcher: null,
        initModal: (d) ->
          @dispatcher = d
        openModal: (url) ->
          d = @dispatcher
          if url!=''
            fetch url
              .then (response) ->
                response.text()
              .then (response) ->
                d 'open-event-modal', response
        editModal: (id) -> 
          @dispatcher 'open-event-modal', id
        closeModal: () ->
          @dispatcher 'close-event-modal',''
      }

I woun't hold it against you if this is confusing! I'll admit to not labelling the methods to afford easy access but once you understand the scoping of AlpineJS I at least find it quite sensible to label methods alike – they will work in unison to get the job done after all.

There's one more 'openModal' in the section header affording the 'Ny konto' (new account)

:coffeescript

  window.sectionData = () ->
    {
      dispatcher: null,
      init: (d) ->
        @dispatcher = d
      openModal: () ->
        d = @dispatcher
        fetch '/accounts/new'
          .then (response) ->
            response.text()
          .then (response) ->
            d 'open-event-modal', response
      closeModal: () ->
        @dispatcher 'closed-event-modal',''
    }


.bg-white{ :"x-data" => "sectionData()", :"x-init" => "init($dispatch)"}
  .px-4.py-12.max-w-7xl.mx-auto.sm:px-6.lg:px-8
    .pb-5.border-b.border-gray-200.sm:flex.sm:items-center.sm:justify-between
      %h1.text-2xl.font-semibold.font-display.text-gray-900.sm:text-3xl.ml-5
        = section_title
      .mt-3.sm:mt-0.sm:ml-4
        %label.sr-only{:for => "search_candidate"}= section_search
        .flex.rounded-md.shadow-sm
          .relative.flex-grow.focus-within:z-10
            .absolute.inset-y-0.left-0.pl-3.flex.items-center.pointer-events-none
              %svg.h-5.w-5.text-gray-400{"aria-hidden" => "true", :fill => "currentColor", :viewbox => "0 0 20 20", "x-description" => "Heroicon name: solid/search", :xmlns => "http://www.w3.org/2000/svg"}
                %path{"clip-rule" => "evenodd", :d => "M8 4a4 4 0 100 8 4 4 0 000-8zM2 8a6 6 0 1110.89 3.476l4.817 4.817a1 1 0 01-1.414 1.414l-4.816-4.816A6 6 0 012 8z", "fill-rule" => "evenodd"}
            %input#search_candidate.focus:ring-indigo-500.focus:border-indigo-500.w-full.rounded-none.rounded-l-md.pl-10.sm:block.sm:text-sm.border-gray-300{:name => "search_candidate", :placeholder => section_search, :type => "text"}/
          %button.-ml-px.relative.inline-flex.items-center.px-4.py-2.border.border-green-300.text-sm.font-medium.rounded-r-md.text-green-800.bg-green-400.hover:bg-green-200.focus:outline-none.focus:ring-1.focus:ring-green-500.focus:border-green-500{ type: "button", :"@click" => add_new_logic }
            = add_new_btn_title

You may notice how I've started "componentizing" the section_header using variables to labels and methods like section_title and add_new_logic – we'll revisit this in another post most certainly.

This partial gets called from the `/app/views/accounts/index.html.haml` like

= render partial: "shared/section_heading", locals: { section_title: t('.title'), section_search: t('.search'), add_new_logic: "openModal()", add_new_btn_title: t('.new') }

All there is left is to adjust the controller. I've moved the renders into templates

  # POST /accounts or /accounts.json
  def create
    @participant_type = params[:account].delete :participant_type
    @account = Account.new(account_params)
    respond_to do |format|
      if @account.save
        @account.set_participant @participant_type 
        format.turbo_stream 
        format.html { redirect_to accounts_url, notice: "Account was successfully created." }
        format.json { render :show, status: :created, location: @account }
      else
        format.turbo_stream 
        format.html { render :new, status: :unprocessable_entity }
        format.json { render json: @account.errors, status: :unprocessable_entity }
      end
    end
  end

  # PATCH/PUT /accounts/1 or /accounts/1.json
  def update
    respond_to do |format|
      if @account.update(account_params)
        format.turbo_stream
        format.html { redirect_to accounts_url, notice: "Account was successfully updated." }
        format.json { render :show, status: :ok, location: @account }
      else
        format.turbo_stream
        format.html { render :edit, status: :unprocessable_entity }
        format.json { render json: @account.errors, status: :unprocessable_entity }
      end
    end
  end

The /app/views/accounts/create.turbo_stream.haml will act on the result of the save

- if @account.errors.any?
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: @account, header: t('.konto') }
- else
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: Account.new, header: t('.konto') }

whereas the /app/views/accounts/update.turbo_stream.haml will do - well almost verbatim the same?!?

- if @account.errors.any?
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: @account, header: t('.konto') }
- else
  = turbo_stream.replace "new_account", partial: "accounts/form", locals: { account: Account.new, header: t('.konto') }
  = turbo_stream.replace( @account )

I'm positively sure this does not even make it to the first beta – for one because it does not really take advantage of the Turbo(stream); it's little more than a bunch of JavaScript incantations not qualifying for much 'turbo' :)

We'll see –

Adam Wathan of TailwindCSS fame is doing a tremendous job rewriting CSS history and David Heinemeier Hansson, Mr Rails, just recently shared Hotwire. That begged a test!

By test I mean building a resource like say /accounts to utilise both TailwindCSS goodness and Hotwire hotness.

Hotwir-ing an index looks something like this:

 / index.html.haml
    = turbo_stream_from "accounts"
    .table.min-w-full.divide-y.divide-gray-200
      .table-row-group.table-fixed.bg-gray-50
        .table-row
          .table-cell.px-6.py-3.text-left.text-xs.font-medium.text-gray-500.uppercase.tracking-wider{:scope => "col"}
            Account
          .table-cell.px-6.py-3.text-left.text-xs.font-medium.text-gray-500.uppercase.tracking-wider{:scope => "col"}
            Participant
          .table-cell.px-6.py-3.text-left.text-xs.font-medium.text-gray-500.uppercase.tracking-wider{:scope => "col"}
            Service plan
          .table-cell.px-6.py-3.text-left.text-xs.font-medium.text-gray-500.uppercase.tracking-wider{:scope => "col"}
            N/A
          .table-cell.relative.px-6.py-3{:scope => "col"}
            %span.sr-only Edit
      .table-row-group{"x-max" => "2"}
        = turbo_frame_tag "accounts" do
          = render partial: "account", collection: @accounts

    / _account.html.haml
    
    
  = turbo_frame_tag dom_id(account) do
    .table-row.bg-white{"x-description" => "Odd row", id:  dom_id(account) }
      .table-cell.px-6.py-4.whitespace-nowrap.text-sm.font-medium.text-gray-900
        = link_to account.name, edit_account_path(account)
      .table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
        /= #link_to account.participant.name, 
      .table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
        = account.service_plan
      .table-cell.px-6.py-4.whitespace-nowrap.text-sm.text-gray-500
        \-
      .table-cell.px-6.py-4.whitespace-nowrap.text-right.text-sm.font-medium
        / %a.text-indigo-600.hover:text-indigo-900{:href => "#"} Edit
        = link_to 'Destroy', account, method: :delete, data: { confirm: 'Are you sure?' }

= turbo_stream_from "accounts" tells Rails to add a pint of HTML for the client to ponder on (or really the Javascript resource which Rails throws into the mix) and start 'subscribing' to a stream which Rails sets up, and keeps publishing to once someone/something Create | Update | Delete  accounts.

= turbo_frame_tag "accounts" do instructs Rails to wrapping the entire set of 'details' in a custom tag <turbo-frame id="accounts"></turbo-frame>

= turbo_frame_tag dom_id(account) do on every detail line does even so – wrapping every row in another <turbo-frame id="accounts"></turbo-frame>

This, however, kills any correct table cell width calculations (probably because the turbo_frame_tag gets in the way of the cells?)

Here's a hack! [ Disclaimer: I'm sure there is a perfectly natural explanation and that I'm just not RTFM carefully ] Meanwhile:

  / index.html.haml
      .table-row-group{"x-max" => "2", id: "accounts"}
        / = turbo_frame_tag "accounts" do
        = render partial: "account", collection: @accounts

    / _account.html.haml
    / = turbo_frame_tag dom_id(account) do
    .table-row.bg-white{"x-description" => "Odd row", id:  dom_id(account) }

Yep - I'm waiting in anticipation for someone with all the 'brass' to come ridiculing me of forgetting something but I've not been able to google the correct way to get this to work!

Now my Hotwire will realtime update my table – and render my index with auto-calculated table cells; and I'm happy!

If you'd like to have your cake and eat it – like reaping all the fruits from this "hotwiring" thing, you'll enhance your controller actions somewhat too:

  def create
    @account = Account.new(account_params)
    respond_to do |format|
      if @account.save
        format.turbo_stream { head 200 }
        format.html { redirect_to accounts_url, notice: "Account was successfully created." }
        format.json { render :show, status: :created, location: @account }
      else
        format.turbo_stream { render turbo_stream: turbo_stream.replace( @account, partial: "accounts/form", locals: { account: @account } ) }
        format.html { render :new, status: :unprocessable_entity }
        format.json { render json: @account.errors, status: :unprocessable_entity }
      end
    end
  end


  # PATCH/PUT /accounts/1 or /accounts/1.json
  def update
    respond_to do |format|
      if @account.update(account_params)
        format.turbo_stream { render turbo_stream: turbo_stream.replace( @account ) }
        format.html { redirect_to accounts_url, notice: "Account was successfully updated." }
        format.json { render :show, status: :ok, location: @account }
      else
        format.html { render :edit, status: :unprocessable_entity }
        format.json { render json: @account.errors, status: :unprocessable_entity }
      end
    end
  end

  # DELETE /accounts/1 or /accounts/1.json
  def destroy
    @account.destroy
    respond_to do |format|
      format.turbo_stream { render turbo_stream: turbo_stream.remove( @account ) }
      format.html { redirect_to accounts_url, notice: "Account was successfully destroyed." }
      format.json { head :no_content }
    end
  end

The important parts being to add format.turbo_stream to each action in order to not reloading the entire 'page'.

Job done.