Curious to gather everyones thoughts now that people have had some time to play around with the dapp experience of Radix DLT and the power of the radix engine. It’d be great to gather more feedback and ideas so builders can keep a close eye and hopefully them build as part of the network. We want participants in the network too, not just holders (although important!). Let me know what you would actually use!
This is based on BTC but has its own public key / private key mechanism.
The landing page has so much on it!
However, one of the entries is for YakkiHonne.
Their link is:-
I suggest you look it up, as it is a very interesting interface.
Beneath this, there is a Markdown editor, which shows the rendered result in the right-hand side panel.
This is also worth looking at.
The reason I found YakiHonne is because of my interest in an individual who sadly died recently, leaving behind his wife and 12 and 10-year-old children. In other words, he was quite young.
His name is Henry Story and he did a lot of work with RDF, FOAF and WebID.
Here is a quite short paper from 2009.
There is also a summary of the paper available in one of the tabs.
FOAF+SSL: RESTful Authentication for the Social Web
There are some of his other publications linked from that website listed here:-
Of note is the 2012 paper:-
Turning a Web 2.0 Social Network into a Web 3.0, distributed, and secured Social Web Application
I must say, in passing, that I don’t understand the very low view counts of his papers as recorded by Academia (academia.edu).
But I won’t go into that here. Apart from that, it seems important to me not to reinvent the wheel.
At the same time, it is important to invent better wheels.
My questions have to do with the subject if people here, considering there are connections between the attention to a particular logic that is expressed in FOAF (SSL) and WebID and SSID that will be implemented on the Radix DLT.
@flightofthefox has mentioned this in Radix DLT Official:-
It’s massive, being able to just store these little bits of data easily in the wallet via the SDK will be a huge boon.
Other platforms - you have to spin up a whole bunch of centralised infrastructure, manage signature proofs, create your own APIs, backup/failover systems, etc.
The simple idea of “hey, what if the wallet can just store stuff on behalf of dApps” (which then has its own automated backups via cloud sync) is much much better
The data creation and storage is also connected with Persona, a central invention on this DLT.
Coming back to Henry Story, would it be more useful than just "fun to have"to be able to map what concepts in RDF FOAF become on this DLT implementation?
I know the Henry Story was interested in Topoi and actually in the Topos Institute in California.
This subject area has some traction on X and is connected with these sorts of mapping exercises.
Is this area of work useful, redundant or just irrelevant to what might be created in UniX, aside from being a possible conversational stream?
Lots to unpack here! I had heard of UniX on Telegram but never looked into it. It’s basically an SDK to implement on games to enable Web3, right? If so, it would definitely help speed up adoption on Web3 games because the biggest hurdle for developers is implementing that part.
I guess that takes quite some time to build though; I don’t know if the best starting point would be a Web3 game such as Parabox “releasing” their own implementation as an SDK, or someone else building it from scratch.
Nostr looks very interesting, I like the fact that they built a protocol, not an application or a service, and gave freedom to everyone to build their own relay. Sort of like Lemmy I guess? Don’t know if you heard of it.
But, on that note, what if I copy my own content from platform to platform?
Is that increasing the reach of the conversation or me being self-obsessed?
I would say it depends on platform to platform. Here, I’d say you’re increasing the reach of the conversation: this thread will get indexed on search engines and someone not even related to Radix might find this conversation.