Unwalled.Garden: souped-up RSS for P2P social apps
pfrazee.hashbase.io
pfrazee.hashbase.io
>missed opportunity
Maybe it's just me, but RSS being all about content is the best thing about it.
* Does Unwalled.Garden automatically pin the content of people you follow, so that their stuff stays online if they aren't?
* I didn't understand "We also use a second “private” dat for records which should be kept off the network". What is this referring to, the follow request, or some other private content like a DM? I assume that since this is still Dat there is no access control if you happen to know the address?
* How is reader privacy and DHT coming along with this ecosystem?
It gets saved locally so you can access it when they're offline. It'll also be possible to instruct your pinning service to seed it on your behalf.
> I didn't understand "We also use a second “private” dat for records which should be kept off the network".
I'll talk more about this in the future as Beaker 0.9 is closer to release. We basically are creating a filesystem with a root dat (which is private). Your public dat will then be "mounted" to it at /public so it feels like one unified FS. The structure will look something like this:
/
/.data/.unwalled.garden/* <- private records
/public
/public/.data/.unwalled.garden/* <- public records
At this stage, I'm pretty sure we're going to need to use proxies to solve this. We're open to using an anonymity protocol like Tor but still uncertain about the tradeoffs.
This update to beaker makes sense to me as it was pretty hard to discover new sites on the network though I’d love to see dat become a bit more stable. I’d often make a site and a friend wouldn’t be able to connect to it. I think if these issues could be resolved is some way the whole network would really take off.
So O(n^2) connections? Might be an issue in the long term. But I like the simple interface.
In following Solid, I've noticed a lot of decentralized projects are interested and adapting to its approach.
If I thought any of the existing standards were winners, I would've gone with them. If you really want to get mad, you can read why I decided not to use RDF or JSON-LD: https://unwalled.garden/docs/why-not-rdf
Activitypub implementations seem to fare mostly fine by ignoring that ActivityStreams2 technically is JSON-LD, using it as "just JSON". Curious if you have any particular points against it (I can imagine a few, but would be interested in your take on it).
Edit: also, thanks!
Except when they do, of course. Some places still have comment feeds.
Still, it's an interesting idea.
I would bet decent money that between Dublin Core, indieweb and various other XML standards of the day, something like that is already defined / describable, it's just not used because the model you suggest doesn't scale well - once comments are in the thousands (which happens, on FB or twitter), single files become unwieldy and the clients get too slow. If you steer away from single files, now you have a protocol that also defines URLs that clients and servers must agree on, increasing overall complexity. It has nothing to do with RSS, a format that has been extendable through XML schemas since 1.0 at least; it's that nobody could agree on such schemas in numbers high enough to make them a de-facto standards, because most actors had an interest in lock-in on their own platforms.
I wish you luck, but this space is hardly new. The challenge is not technical, it's entirely a political one - a lot of people have to agree and implement a standard and then reach some sort of critical mass without triggering the search for lock-in.
Today all of those are dead now in favor of ActivityPub. AP loses a lot of the simplicity that could make RSS ubiquitous (you need a home server and na application server to handle api calls) but the expected interactions are all there, and it's built to be extensible.
In fact, I think reusing the "everything is a file" is definitely cool and makes things easier to try, but you would definitely benefit from using the whole JSON-LD taxonomy. Things are already defined and have been used for some time in production, so you can expect some work has been thrown at it. It'd also make collaboration easier.
{
"topic": "dat://unwalled.garden",
"body": "Why didn't you use XML!?",
"createdAt": "2018-12-07T04:15:44.722Z"
}
Just use XML. Preferably, extend one of the existing RSS-like formats. Apply lessons learned from HTML and XHTML. It will work zillion times better in the long run.
The format really isn't the interesting question. The interesting question is how do we get clients to behave predictably with each other. If you start breaking the schemas that everyone on the network is using, then yes your posts should fail to render and probably be ignored.
Without defining these schemas to allow for flexible mixed media documents, you're always going to have chaotic implementations floating around.
How is that different from XML if your body is defined as a text field?
what is the argument here? why didn't you know you answered your own question
"body":"Why didn't you use <img src="xml_has_its_uses.png"> XML!?"
You're assuming HTML string, which might not always be correct. What do you do with Markdown?
You need to have a standard way to represent things like this, because otherwise it won't gain traction solely due to the immense complexity of implementing viewers.
Edit: On top of this, HTML might not necessarily be the best choice. In that case it'd just be browser wrappers galore.
everyone is already used to making their frontend, backend and database parse and store external things in key value pairs
this schema pre-detecting ship has sailed a long time ago
{"body":{
"childNodes": [
{"span":{"textContent":"Why didn't you use "}},
{"img":{"src":"xml_has_its_uses.png"}},
{"span":{"textContent":" XML!?"}}
]
}}if you wanted to "include images or something of that sort" you would add an "images" key or a "something of that sort" key
in your particular example, body can clearly take image links image data as string and the parser can deal with it.
in my projects we typically would have a nosql database which out the box allows it to be indifferent about objects in a collection/table that include or exclude certain keys
>and the parser can deal with it.
That's not ideal. You need a defined schema so that the majority of parsers can reliably parse the majority of objects.
>in my projects we typically would have a nosql database Parser implementations shouldn't be assumed to use the same or similar tech stack that you do.
As long as your body is a plain text, you can present it in a very wide variety of ways and styles. Once you allow formatting and inline images, you start moving towards HTML documents, and lose consumer's control over content.
Also, this sort of "use this, not that" dismissal ignores the fact that almost every decentralized application can be bridged together. It would not be hard to have Mastodon/Pleroma pull someones Unwalled.Garden feed and put it on its federated timeline, or conversely for Mastodon/Pleroma to expose its users feeds as Unwalled.Garden files.
body: string