I'll kick off the conversation thread. Let me know what you think, either here or in the article comments.

It's aimed at non-techies, so don't pull me up on minor technical issues! One thing I should say: I've had to use the word "object", because it's what people will understand, and there's no other word in general use for what they are. But they're not OO objects, they're data chunks that are "internally animated", so the inverse of OO objects which are method-wrapped data.

@Leonard Pauli thanks for the ❤️! But did you subscribe? 🤗

Yes! Smashing up apps and data-silos to concept based self-attaching nodes, is the way. I like the excel-like logic basis, allowing introspection and mouldability. I've been thinking up a similar track... could you make it even higher level? Where the data isn't just random binary/half-labeled spreadsheet cells, but actually modeled/given meaning through canonocalized constraints/relations? Possibly opening up for not just modular components, but fully dynamic interactions self-assembling from slices of information?

Also, seen urbit? The focus on local first sharable personal data-owning, in introspectable non-blob format, with separate logic/functionality layer, and yet separate render/ui layer...

Love the concept of semi-physical rooms! A place for chat, a place to hang, a place to research! All designable by you, the end-user, through components you've found on your travels through the lands! YES!

When you link the presence sensor to the lamp, how does it know? Sane defaults akin to node n noodles connections? What about wanting a dimmer? Delayed turn-off? You make those as connection boxes (node n noodles or sheets) in between? Fun indeed!

Many AI solutions still suffer the "better horses" problem, the end-user needs to be empowered with a language to communicate their desires. Even reading the mind might not be enough, as the right language gives you the mental clarity in the first place. AI solutions could still guess well, and gather own experience... but if we want to include the human... Even without, the AIs themselves need inter-communication and clarity of thought. I'm proposing work towards a system facilitating such. A system where the current grunt-work of software development isn't applicable anymore, because of different abstraction levels and perspective. A system where the freedom and flow of creation and collaboration is found at yet a higher level.

So, firstly, yes, you'd have slightly different render of a given standard object type depending on context, whether in a list or embedded in another object, or pulled out on its own into the space. However, there's no need to do a different render for 2D and 3D: it'll be the same one. I'm thinking neuomorphic in both. (It's using Vulkan for both, underneath.) You wouldn't get a CV if you printed it, no, you'd have to jump the link from the contact card to the person's CV. If you were viewing the contact in 2D, then expanded the embedded link to the CV - seen as a smaller panel inside the contact, then hit "print", you'd get what you saw, with the CV. So yes, there's both some hard coding of behaviours of objects, and a default render of any standard recognised object type. But you can extend both. You suggest AI help for programming? And working at a higher conceptual level? I've probably over-summarised your point, so apologies there. So, I'm not working on AI or AI-to-human, etc., conceptual languages, except the programming language is declarative so intended to be humane, unlike imperative ones. It's what I call a "Domain and Target Independent Language" that is meant to be general purpose and conceptually intuitive without being Nat Lang.

Exactly! If the contact card needs a link to the CV, where is the data!? Eg. the name, and profile picture? Are they both linked in each, or duplicated? If linked to the person entity/node, RDF style or similar; then can the CV not be a virtual construct from available info in the graph, with possibility to override the heuristics on a case by case basis if needed, or even better, update the heuristics to facilitate improved CV's all over?

Eg. obsidian style, is the card and the cv separate but linked .md files, with info duplicated; or is each property atomic, and related rather than linked, such that a generic CV view could be shown?

Auto adjusting with time?

I had another look at Urbit, and it's interesting, but the "single function OS" over a persisted event log type of thing isn't really my kinda stuff. It could end up being similar to the Object Net and Onex from an end-user PoV, but I could find nothing on the site about why anyone would use it, what it would look like in the HX, etc. And, as soon as I see the "B" word (b..b...bb..blockchain!) I usually hit the quit.

More at: https://frest.substack.com?utm_source=navbar&utm_medium=web&r=qz3e6

The UI should be somewhat like Access or FileMaker, giving the user the direct ability to manipulate the relational data storage. Users can quickly become quite adept at manipulating relations. My FREST project is in part about making that distributed. I should be able to “join” multiple, distributed data sources and functions in an ad hoc manner.

@Konrad Hinsen Yes, it's conceptually "simple" to have an OS without apps, but "building" will indeed take from now until my last breath... All our data will be out there still, so as long as you have an API to those photos on Google, you'll be up and running! Things like email and the static web, and many chat applications, can be brought in to the Object Network. Anything that allows data to be grabbed (and shoved!) - via a protocol or a filesystem. I could even (reluctantly!) allow for old fashioned apps to be rendered in-world, starting with (and maybe ending with!) a browser. But I'm currently seeing the project as a "Lab" for Proof-of-Concept work, where I don't need to make any compromises such as that. I recently let go of any hope that anyone would be using it any time soon, to be honest! But things like blockchain stuff and Urbit, even though I'm not a big fan of either, do give me hope that completely new things can gain traction.

I've been going back and forth between different entry points on the behemoth of foc... text language, logic engine, data engine, graphics engine, networking component... slowly realizing that working consistently productively alone is the first one to tackle, so going back to basics making quick playtoys to get the doing muscle warmed up again; ie. would love to get something like endless paper (infinite zoom/pan canvas) going (rust+wgpu) + published, then MMO functionality added, text rendering, dom-element attachments, obsidian integration, rust+gpu fn node n noodle graph playground (just take monaco editor as dom attachment) and we're of to the races.

"off to the races" sounds like it's as far away for you as me!

Got a link?

actually I think I've found you on GitHub, so I'll potter around in there for a bit...

To me both seem quite similar to the original Smalltalk approach - there is no data, just objects that represent computational processes

Hey, @Ivan Reese - isn't @Alexander Obenauer your work colleague at Ink-n-Switch, now? Why isn't he on this site these days? We could use his input in this thread to prevent my misrepresenting his ideas!

Right, AO does have some stuff on networking as pub-sub and event-action "automations": https://alexanderobenauer.com/labnotes/021/ https://alexanderobenauer.com/labnotes/025/ https://alexanderobenauer.com/labnotes/026/ https://alexanderobenauer.com/labnotes/027/ They seem to sprout organically from the itemised (local-first) ideas, rather than being core to the project - taking up a small percentage of the Lab Notes output.

I recommend this demo of a reconstituted 45 yr old Smalltalk-78 system, which seems to match both your goals -

Smalltalk-78 + modern networking + color support sounds a lot like what you both describe

@Naveen Michaud-Agrawal I'm just watching now... 😄

Here's the paper describing the process of revival: http://esug.org/data/ESUG2014/IWST/Papers/iwst2014_Reviving%20Smalltalk-78.pdf

Found the Byte magazine: https://archive.org/details/byte-magazine-1981-08/page/n79/mode/2up and I'm having an emotional reminisce... 🥹

You can understand why Ted Nelson and Alan Kay are so grumpy about things

If only the youth of today would listen to us grumpy oldies.. 🤣

@Guyren Howe I don't agree about the "component web" model you suggest. But that's another thread probably...

After poking around in Urbit for a while being utterly baffled why anyone would give it even a cursory evaluation, let alone having such an apparently vibrant community - is it a ponzi scheme? what on earth do people do with it? where does the money come from for those fancy meetings? - here's an article that also has .. questions: https://wejn.org/2021/02/urbit-good-bad-insane/

All I can think is that it's a nutcase project given a huge lift-off when they decided to use Etherium - it simply seems to be worse than vapourware: software that exists but may as well be vapour.

Also it helps to remember that Smalltalk in the early 70s was built on today's equivalent of a $150k machine (I've seen figures that the original cost of the Alto was about $20k dollars in 1972)

Declarative has been described as "say what not how" - and this is about "what" state you want, not a prescription of "how" it should be achieved

I believe an HX (human experience, UX) built around goals and intended states is, well, better. Worse of all is where you get the two mixed up: is that button telling me the current state, or the state I'll get when I hit it?

So, back to the Smalltalk points that led here... Back in Kay's day, Big Tech was represented by IBM, and their "app trap" wasn't surveillance capitalism as it is today, it was the provision of closed, proprietary application Blobs that fragmented and Balkanised a customer's data. You had to pay huge sums to them - effectively ransom money - for access to the applications that allowed access to each type of data they would let you manage: maybe payroll, maybe accounts, etc. If you didn't pay up, your data was essentially lost. And you certainly wouldn't be able to cross-link your payroll or accounts data with data in any competitor's applications. So maybe this was a driver to Smalltalk's particular model of an "OS with no applications" - the desire to restore to primacy the precious users' data. Without applications, you just had all different types of data available to you, all visible and interactable in the GUI, to mash up how you liked. Those chunks of different types of data were called "objects", of course. Kay's objects had methods or messages on the outside - the API - and held data on the inside, inaccessible directly to other objects. So in a way, they were like "mini-Blobs" - they still wrapped the precious data, but at least that data was no longer beyond a user's access or control. Now, my claim is that this was "almost there but not quite", at least if we're talking about non-technical users, faced with the Smalltalk object model; if we want an "OS without applications" that "normies" can use - one that makes their data first class over the rather difficult code. What's missing is what I call "The Inversion". The Inversion is the dramatic choice point that moves you from Imperative to Declarative style. If the goal of an "OS without applications" is to free our data - to restore its primacy in the user's experience - then it's a shame to give up at the last hurdle! Why not go all the way and make data truly first class - all the way down to those little objects? Why not de-Blob the objects too? Just put the data on the outside, and hide the behaviour! That's The Inversion: "What not How". It was still the 1970s when an application was released that did acknowledge the power of the Inversion: Visicalc. With Visicalc you saw the data in your spreadsheet cells before the functions behind them. But the Smalltalk and Visicalc models were never merged into "an OS without applications for non-techies". Which is what the Object Network and OnexOS are doing, right now!

Yes, OK, @Konrad Hinsen and @Naveen Michaud-Agrawal - it took me 2 days to come up with all that! Thanks so much for the prompting from both of you!! You really got me thinking - I always dismissed Smalltalk because of it being the archetypal OO system, and imperative, but now I do see how important it was in the sense where it's not just a programming language, but a more holistic concept of empowering the user.