Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unwalled.Garden: souped-up RSS for P2P social apps

pfrazee.hashbase.io

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#31

Post by pfraze »

zcopley wrote: post #30
nonwifehaver3 wrote: post #3

Earlier quoted context omitted.

Every existing ActivityPub application requires you to rely on a server operated by someone else that controls your identity. This application puts you fundamentally in control of your content: it is just served from your own device by default, with the option to have another server pin your content (all of your content has Dat addresses). Also, this sort of "use this, not that" dismissal ignores the fact that almost…

Okay, but why RSS over Activity Streams?

It's not actually RSS, it just uses a very similar model of static files shared off websites.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#32

Post by cblades »

rolltiide wrote: post #28
gambler wrote: post #23

Anyone who tries to use JSON for complex, extensible formats that involve documents (as opposed to data structures), metadata and semantic data are shooting themselves and their users in the foot. Just because W3C fucked up in some of their XML-based standards doesn't mean that trying to shove JSON everywhere is a sensible idea. { "topic": "dat://unwalled.garden", "body": "Why didn't you use XML!?", "createdAt": "201…

can you explain that example more clearly? 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…

Not who you're responding to, but:

>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.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#33

Post by theamk »

gambler wrote: post #23

Anyone who tries to use JSON for complex, extensible formats that involve documents (as opposed to data structures), metadata and semantic data are shooting themselves and their users in the foot. Just because W3C fucked up in some of their XML-based standards doesn't mean that trying to shove JSON everywhere is a sensible idea. { "topic": "dat://unwalled.garden", "body": "Why didn't you use XML!?", "createdAt": "201…

I think inability to include images it is actually a feature.

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.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#34

Post by jjdjr0odo7 »

cblades wrote: post #32
rolltiide wrote: post #28

Earlier quoted context omitted.

can you explain that example more clearly? 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…

Not who you're responding to, but: >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.

Over generalized solutions smells like premature optimization

Solve for the problems at hand, not ones we can conceptualize.

If a stack works fine, why does the parser picked for that stack need to be anything else than what’s working?

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#36

Post by grenoire »

rolltiide wrote: post #29
dpe82 wrote: post #27

Earlier quoted context omitted.

How do you express "Why didn't you use XML!?" with json?

you don't, you just store the string as is in the body tag and let the client side parser know how to parse html strings that may also include an image tag what is the argument here? why didn't you know you answered your own question "body":"Why didn't you use XML!?"

OP is asking what the content type of the body is to be interpreted as.

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.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#37

Post by grenoire »

pfraze wrote: post #24
gambler wrote: post #23

Anyone who tries to use JSON for complex, extensible formats that involve documents (as opposed to data structures), metadata and semantic data are shooting themselves and their users in the foot. Just because W3C fucked up in some of their XML-based standards doesn't mean that trying to shove JSON everywhere is a sensible idea. { "topic": "dat://unwalled.garden", "body": "Why didn't you use XML!?", "createdAt": "201…

There's nothing stopping you from extending the JSON schema. We'll probably come up with extension points to make it easier (as subobjects, each declaring their own schema IDs). 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 fai…

The format is exactly for the purpose of getting clients to behave predictably!

Without defining these schemas to allow for flexible mixed media documents, you're always going to have chaotic implementations floating around.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#38

Post by api »

theamk wrote: post #33
gambler wrote: post #23

Anyone who tries to use JSON for complex, extensible formats that involve documents (as opposed to data structures), metadata and semantic data are shooting themselves and their users in the foot. Just because W3C fucked up in some of their XML-based standards doesn't mean that trying to shove JSON everywhere is a sensible idea. { "topic": "dat://unwalled.garden", "body": "Why didn't you use XML!?", "createdAt": "201…

I think inability to include images it is actually a feature. 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.

You also invite degeneration into an imageboard which ends up being a wall of memes and stupid jokes.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#39

Post by toyg »

pfraze wrote: post #21
Semiapies wrote: post #20

"Unlike Twitter and the other social networks, RSS never tried to capture the social graph, likes, comments, annotations, retweets, and etc of its userbase." Except when they do, of course. Some places still have comment feeds. Still, it's an interesting idea.

Yeah I knew there had been some shots at it, but my google fu couldn't pull up anything solid to point to. I'd love to see if somebody ever tried to "go big" with RSS. EDIT: also the comments RSS is generally comments posted to the blog, right? Not quite the same thing as each user having their own RSS feed with their posts and comments.

> I'd love to see if somebody ever tried to "go big" with RSS

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.

Re: Unwalled.Garden: souped-up RSS for P2P social apps

#40

Post by rakoo »

pfraze wrote: post #21
Semiapies wrote: post #20

"Unlike Twitter and the other social networks, RSS never tried to capture the social graph, likes, comments, annotations, retweets, and etc of its userbase." Except when they do, of course. Some places still have comment feeds. Still, it's an interesting idea.

Yeah I knew there had been some shots at it, but my google fu couldn't pull up anything solid to point to. I'd love to see if somebody ever tried to "go big" with RSS. EDIT: also the comments RSS is generally comments posted to the blog, right? Not quite the same thing as each user having their own RSS feed with their posts and comments.

The thing is, RSS is about dissemination of content while follow/like/comment is more about dissemination of opinion. There were indeed some protocols to fill the missing pieces, including json-ld for having some sane, common format and the Salmon protocol to make information go back up to the source. Like a salmon. But it definitely was a patchwork of multiple technologies with various advancement status and quasi-inexistant documentation.

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.

Post reply on HN