-> @haileys.quest

the YIF Image Format

I'm sorry, the location on this being Cary is distracting me

Why Cary of all places?

RE: @paul@oldfriends.live

I'm knee deep again in this idea of a command-palette oriented operating system...

Everything runs through command palette plugins; the plugin system would let you register search providers and global-search entries (which also includes "home screen" list entries you can scroll through) through standard channels (Unix sockets, D-Bus, and individual plugin files). Registered entries would point to how that plugin can be invoked (Unix socket, D-Bus, spawned process I/O [recommended], and HTTP/S), which it doesn't always need to do (sometimes it just opens a file or URL). The only thing actually built in would be the command palette settings. (The operating system would supply a bunch of plugins; some of them as separate packages, and some of them as plugin files.)

It'll be based primarily around a few Views:
* A special Global Search View, which is the default view. It's like the search view but the command palette itself serves the results, based on what plugins have given it. The command palette orders the results (though, you may be able to delegate this to a plugin at some point). Shows the input box at the top.
* Search view, which is your typical command palette view containing a list of search results and widgets. A plugin opens the search view and controls its appearance and all of its entries, including the order. Shows the input box at the top.
* Reader view, which contains rich text and some widgets. Non-interactive and uses the up and down arrow keys to scroll. Some key actions may be available. The input box doesn't appear in this view. Shows a title and a back arrow at the top.
* Code view, which is similar to reader view but it shows a code window instead. It may be editable. Scrolling is based on the text cursor. The command palette handles syntax highlighting, but custom highlighting can be applied by using "ansi" as the highlighting language and embedding ANSI escape sequences (which will be stripped when copied). Shows a title and a back arrow at the top.
* Terminal view, which shows command output. No input box, all input is captured by the terminal itself, including escape (but excluding the mouse while it is outside the terminal borders). This may be the OS's main terminal, but chiefly, it is just used to show the output of CLI commands and make them interactive if they need to be. (Think of this as the natural extension of the Run tool in the Windows Command Palette.) Shows a title and a back arrow at the top.
* Chat view, which moves the input box to the bottom and displays chat bubbles in the new space above it. You can use this to quickly check text messages or, of course, use LLM chats. Chat bubbles can have buttons & auxiliary (menu) actions, and you can press up from the input box to start navigating them. You can edit your own messages if the plugin serving the view allows it, by selecting the message and pressing enter. In the input box, pressing Down expands suggestions, if there are any. If there are suggestions and the input box is empty, it shows the first suggestion(s) in a reduced-size space. When returning suggestions, the plugin can tell the palette to show the suggestions in "active" mode which expands the suggestion space similar to the regular command palette. When messages link to each other (i.e. replies), a view-specific history is kept so you can backtrack your link-following, and scrolling to the very bottom clears that history.
* Image view, which shows an image in the window. No input box. Actions can be bound to any key except Escape, which always backs out of the image view. Shows a title and a back arrow at the top.
* Form view, which lets a plugin accept multiple inputs, including some that aren't available in other views such as multiple text-boxes, drop-downs, and switches.
* File picker view, which shows a grid or list of files to pick. The files can either be from the system (a file picker prompt) or provided by the plugin (i.e. a cloud file browser). You can type in the input box to filter, or put in a specific path to show and pre-select that file. Depending on the files being searched for, it might have a gallery view. (The file picker might also have its own plugin system, so you can pick files from the network [i.e. a phone connected via KDEConnect, or Immich, or Nextcloud, etc] more easily.)

Widgets, which show up with results in the Search and Global Search views, have some formatting powers but they're mostly text and images; they can also have buttons. The main use cases for widgets are things like calculations, conversions, IP addresses, and suchlike. They also have a maximum height (about half the palette's default height). If they have buttons, the first button is selected; if it doesn't, the next widget button or search result is selected.

The OS would have built-in plugins for SMS/MMS and dialer on devices with modems (maybe), managing Nix packages, managing Flatpaks, managing Cpaks (maybe), Web search (primarily suggestions), file search, app listing, calculator, unit converter, searching system settings, and some other stuff I forget. There will be "official" plugins as well for (fiat) currency conversion, XMPP (maybe), and Wikipedia search (ideally with a limited local index).

The file search plugin should use annotations and conditions to hide its entries when another plugin declares a "file" annotation for the same file.

I think the biggest thing I want in #DeltaChat is a "unified inbox" where, unless I specifically exclude it, chats for all of my profiles are listed. Any duplicate contacts would show the profile icon on the list, and if I have multiple accounts in the same group for some reason, it would let me switch between them in the composer.

Seems like it would be rather simple? There's probably some implementation detail I'm missing.

(For a more advanced implementation: you'd be able to start with one easy unified inbox, and make other unified inboxes if you need to, selecting and deselecting as you see fit. Mostly the idea would be you can have multiple personal ones, multiple work ones, maybe a few for volunteer groups: maybe some of them use an online name, maybe you have a deadname on one profile and a chosen name on another, maybe you have individual profiles for each group you join... So you might have your personal ones grouped, your work ones grouped, and your volunteer ones grouped... but for most people, myself included, a singular unified inbox with exclusion should work just fine!)

Something I realized recently when I found a phrase for it: protocols can only go so far, then they get stuck in the past. XMPP is very much like this, HTTP and email are, and even IP itself (cough cough IPv6). Central development gets around all of that -- and you can still use protocols.

The best example of this model I can think of is DeltaChat's core library & app set. You can use that core library pretty much anywhere, and build an app off of it that's fully featured up and down. Better, since it has a better development concentration than a protocol-only model, the apps for each platform are native, or at least more native than they would be using something like Electron, Tauri, Flutter, or React Native. You can, of course, start with a core library and any of those (preferably Tauri or Flutter), and grow to support centrally-developed native apps over time.

For cases where a core library approach won't work, you can always fall back to encouraging forking and contributions by not breaking things (maybe a modular or plugin/mod-based approach as well). This is basically the model of (good) modded video games, where you can edit the ever living hell out of it and it's largely compatible.

Central development also means that some group is responsible for coordinating developments across participants in the protocol. Forks can then rebase. This cycle, well maintained, often means you get support for new features across the ecosystem a lot faster than a fully protocol-only model.

Good central development, of course, must be FLOSS, to allow and encourage development by third parties.

(Term list: central development, core library approach, modular approach, plugin-based approach, centrally-developed, protocol-only model)

The certificates on my XMPP account have expired yet again, there's also some unknown DNS-related issue that's had my account defederated for a good while now. Honestly I don't feel like trying to solve it and there's not much reason to, so I think I'm just going to turn it off.

@foone@digipres.club A hyperlink I would recognize anywhere.

@drwho@hackers.town @cwebber@social.coop I put a lot of trust in the founder and other developers. I don't trust their board. edit: by founder I mean Jay, not the Twitter guy

@gooba42@mastodon.social @cwebber@social.coop It's TECHNICALLY possible to exit, but financially unfeasible. They started by treating themselves as a potential threat, building that into every aspect of the protocol (except, notably, Bluesky itself), but they just didn't get far enough before the enshittification started.

@f2k1de @GossiTheDog zero tracking cookies

@stadsplanering @mhoye for fahrenheit/celsius specifically, I'm of the opinion that fahrenheit is better for the sole use of "what's the weather outside," because it does roughly (roughly!) correspond to body temperature: 0 degrees is 0% hot, 100 degrees is 100% hot. Celsius very much does not. In all other cases, Celsius is better, but in this specific, everyday use of temperature, Fahrenheit is the way to go. Because in Celsius, 21 and 22 is a big difference, and you kinda have to already know that 30° is "hot," whereas the number 100 carries that meaning intuitively. The rest of metric doesn't have this, though, and it is one case out of many (the other everyday use of temperature is cooking/baking, where Celsius makes more sense.) Canada does this kind of thing a lot, actually: they'll use US customary ("Imperial") units in some situations and Metric/SI in others. Sometimes it makes sense, sometimes it doesn't. (Even though, like the US, everything is defined in terms of Metric.)

@stadsplanering @mhoye "just" you have no idea how deeply ingrained it is here. it's not going away. plus we can't even get rid of daylight savings time and everyone wants that

@aparrish@friend.camp ⁿᵒᵗᵉ ⁴

@evan@cosocial.ca @danielsiepmann@friendica.daniel-siepmann.de @fediversenews@venera.social @erlend@writing.exchange I think they don't realize ForgeFed is based on ActivityPub (although I think it doesn't use AS/2). So it's most definitely fulfilling that use case.