Outlook: a connection layer in the app

Proposal to the app team, not in the app yet. Everything on the other pages applies unchanged. This page shows where things could go, so you can build accordingly today.

Today and with a connection layer

What it would mean for your tools

• Less code: the app would take over checking, sorting out duplicates and picking up. A tool would only need a small, clear interface. Self-built and AI-made tools would benefit most.
• Linking across languages: an English tool could report to a German one, because the kind counts, not the name.
• New kinds of tools: with mediated hardware, ideas that fail on isolation today would become possible, such as a step counter, a spirit level or a tuner.
• One state instead of copies: shopping list and pantry tracker would read the same collection and could no longer drift apart.
• More security: hardware without lifting the isolation, and visible rights per tool and collection.

The proposed stages

1. Now, without changing the app

   The shared kit is the connection layer on the tools’ side. All interaction runs through one single place there. When the layer arrives in the app, only this place is swapped; the tools stay unchanged.

2. Small app change

   Declaration in the file (what a tool sends, understands and lets others set), routing by message kind, notification of new inbox entries, reminders.

3. Mediated hardware

   Photo, level, motion, orientation and notification as separate rights, without lifting the isolation.

4. Shared collections

   A local database with rights per collection and notification of changes. First “einkauf” and “personen”.

What it costs

• The work lies in the app, not in the tools or on this website.
• The layer is a point of attack. It needs strict checks and must show which tool may do what and has done what.
• The interface must stay small and versioned, otherwise every app update breaks tools.
• Every tool must still run on its own. Each capability is checked before use and simply drops away without the toolbox.

How to build future-proof today

• Let all interaction run through one single place in the code. If the interface changes, you only swap this place.
• Use the shared envelope { typ, v, id, text }. Messages with kind and version could be routed by kind directly.
• Keep what your tool sends and understands in one place, for example in the CUSTOMIZE block. That matches the proposed declaration in the file.
• Check every function individually before using it, not just window.ARTEFAKT. That way your tool runs with older and newer versions of the app.
• Store data so it can be represented as JSON. That fits the backup, exports and future collections.

// All interaction runs through this one object.
// If the app gets a new interface, you only change this part.
const Connection = {
  available: () => !!(window.ARTEFAKT && typeof ARTEFAKT.senden === 'function'),
  send(target, typ, fields, text) {
    if (!Connection.available() || !target) return false;
    const n = { typ, v: 1, id: Date.now().toString(36) + Math.random().toString(36).slice(2, 6), text: String(text || '').slice(0, 500), ...fields };
    try { ARTEFAKT.senden(target, n); return true; } catch { return false; }
  },
  pickUp() {
    if (!Connection.available() || typeof ARTEFAKT.eingang !== 'function') return [];
    try { return ARTEFAKT.eingang(); } catch { return []; }
  },
  open(target) {
    if (Connection.available() && typeof ARTEFAKT.oeffnen === 'function') try { ARTEFAKT.oeffnen(target); } catch {}
  }
};

// In the tool: report after an exercise
Connection.send(KONFIG.ziele.erledigt, 'erledigt', { was: 'Breathing', menge: 5, einheit: 'min' }, 'Breathing, 5 minutes');

See also: Shared messages · What the toolbox handles