Dropping this one from the marketing hook thread which spawned this topic.
a share anything app which does all the setup for you so anyone can do it without realising they’ve reserved a name, uploaded a file etc. They select, add some text, then click publish, save (private) or share (private+selected viewers) kinda thing.
However, if you do understand you’ve uploaded a file, where you might be able to find it again in its raw form, and what else you might be able to do with it, I’d argue that’s a really powerful tool.
Is that a reply to me? If so I think that’s covered. The app can maintain and index on the network of what the user has done, which can be searchable against time and other metadata, and a keyword index based on content of that’s useful.
Yes, sorry!
Absolutely, not doubting it can be done.
I guess in these early stages I’m just thinking about making sure corners don’t get cut, and the norms that are established demonstrate the full benefits of the network, rather than devs who are rushing in from the clearnet, trying to get first mover status or whatever.
No doubt we’re all on the same page there, it’s just a question of what kind of apps can demonstrate that with maximum speed and minimum dev input, and be of immediate use to the end user.
But it has to be paid for doesn’t it?
Of course. But it should be easy to do, and when it’s been clipped it would then be accessible by anyone for free.
I think this is a really interesting point, which I was trying to articulate above.
We’ve never had a situation where a URL can reach any data item indefinitely. We have situations now where URLs come and go, access is granted or restricted (preventing leaching, etc), the content at the URL changes, and so on. To have a situation where everything can be resolved to a URL, which can be accessed by everyone, is massively powerful.
The network itself is a REST service, it is the database, it is the file system. It is all available for access by any apps. Even the app repos are on the network, ready to be executed directly from their URL too (as content is guaranteed to be the same).
I was pondering last night what this could mean for how we think about data and apps in general. From wikipedia, Object Oriented programming can be distilled down to:
Object - oriented programming ( OOP ) is a programming paradigm based on the concept of " objects ", which can contain data and code
Can joining the app with the data together in a message be considered an object, in the programming sense? If I send someone a message which contains both the data (or a link) and suggested code (or link) to process it, does this provide something unique? Could this code be run against the data in a sandbox? Does this unlock something new and powerful?
I think we are going to quickly realise the need for standard message formats. Maybe something simple like a JSON format, with a header defining meta data (type, encoding, title, etc) and a body containing some sort of payload.
If an app knows what types it can deal with, then we can have a mixture of apps processing/rendering compatible messages. Perhaps the source becomes more important that the type? Some sources are twitter style feeds, others blog style feeds, other IMs, forum posts, emails, etc.
While CMS UIs and such will be helpful, I think Safe Network will be capable of so much more. Interoperability will be on another level and publishing something will be far more powerful than right now.
Some may point to publishing costs, but this is also spam protection. Small data publishing will be super cheap - micro payments, small fractions of pennies, IMO. I don’t think we should fear this, but see it as an advantage. The costs are spread to the data creator rather than centralised at the app/data host.
Having functions with some metadata, versioned and available at a url could be interesting. Especially combined with a search engine so you could search for all functions that can process some specific data or data type and then having all the data easily available too.
Here’s an interesting blog post with some ideas on making the internals of apps more open and shared, maybe SAFE could help with something like this
https://pchiusano.github.io/2013-05-22/future-of-software.html
Thanks for the link - it was an excellent read and safe network could definitely deliver in a similar way.
With safe, I could imagine scripts or functions being associated with data feeds (appendable data). An app could be the wrapper which defines the data feed location, any filter scripts, and an output formatter. Depending on target platform (output type) a different formatter could be substituted.
An app becomes the data and the code. All native to the network and interchangeable.
I’m starting to think that the killer app isn’t going to be a specific app itself, but the whole way apps and data can be shared and combined. An entirely different and more flexible way of making apps shape the data around us.
I can’t wait to see this start to take shape!
Sounds like the sort of thing @gsvarovsky is thinking about too Live data sharing with CRDTs - #14 by gsvarovsky in his efforts to rid the world of data wrangling.
Thanks for the shout @JPL, and for the link, @intrz! A wonderful rabbit-hole of ideas, leading to the author Paul Chiusano’s current work on Unison, a programming language with content-addressable code.
The ideas I have been pursuing have been oriented to data (and with m-ld, to concurrent editing of shared information). Recognising of course that code is data – I’m looking forward to the first CRDT for a language syntax tree…
Also have a look at the newly-minted braid.org, which, while focusing on distributed data, also has wider aspirations for providing a better way of composing applications.
It would be interesting with a language where what was stored was the abstract syntax tree and you had one or more compiler and “reverse” compilers, so you could write the code with different syntaxes. You could then even have both textual and graphical interfaces to the code, but the actual code itself would just be stored as the abstract syntax tree using CRDT.
Unison seems quite interesting and there’s also a web assembly version.
From the docs:
Unison definitions are identified by content. Each Unison definition is some syntax tree, and by hashing this tree in a way that incorporates the hashes of all that definition’s dependencies, we obtain the Unison hash which uniquely identifies that definition. This is the basis for some serious improvements to the programmer experience: it eliminates builds and most dependency conflicts, allows for easy dynamic deployment of code, typed durable storage, and lots more.
When taken to its logical endpoint, this idea of content-addressed code has some striking implications. Consider this: if definitions are identified by their content, there’s no such thing as changing a definition , only introducing new definitions. That’s interesting. What may change is how definitions are mapped to human-friendly names. For example,
x -> x + 1(a definition) as opposed toNat.increment(a name we associate with it for the purposes of writing and reading other code that references it). An analogy: Unison definitions are like stars in the sky. We can discover the stars in the sky and pick different names for these stars, but the stars exist independently of what we choose to call them.
It seems these Unison definitions are stored in files named after the hashes. A SAFE version of Unison could swap the hashing algorithm for what’s used on SAFE and store them on xor adresses. Then all references to some code could point to locations on SAFE and you could always be sure that any referenced code would always be available and that it does what it’s supposed to.