The IndieWeb needs to believe in itself (2018) | Hacker News Reader

The IndieWeb needs to believe in itself (2018)

fogknife.com

95 pointscameronbrown17 comments

My interest was piqued enough by this post to go clicking around the IndieWeb site for more information on Webmentions, and I was amused to see, on the page where they discuss an earlier spec that attempted to do the same thing, TrackBack (https://indieweb.org/Trackback), a link to an essay I wrote 14 years ago critiquing the thing that ended up killing TrackBack -- its complete lack of spam-proofing. (This one: http://anthillcommunities.com/archives/001653.html)

I guess somebody actually read it! Huh. In unrelated news, now I feel old :-D

I was curious to see how Webmentions sets out to avoid the same problems, since they should be more obvious today than they were when TrackBack was created in 2002. The answer appears to be one of your classic "good news/bad news" situations.

The good news is, it appears some thought has been actually been put into spam-proofing this time around. The Webmentions spec lays out a verification process that incoming Webmentions MUST pass in order to be accepted as valid (see https://www.w3.org/TR/2017/REC-webmention-20170112/#webmenti...), which is good.

The bad news is, assuming I'm reading the spec correctly, that verification process boils down to "do an HTTP GET of the page that supposedly linked to you and parse its HTML to make sure there actually is a link to you in there," which doesn't seem like much of an anti-spam speed bump. All your spammer has to do is send all their Webmentions from the same URL, and then publish an automatically-updated list of links to all the URLs they've spammed over the last six hours at that URL, and boom, they're valid, right? Or is there something I'm missing here that makes this more spam-resistant than it first appears?

Just my opinion, but I'm not sure that the antispam should be built into the protocol itself. There's nothing there that say the receiver MUST NOT perform additional checks on the sender. Furthermore section 4.1 says that the receiver MAY moderate webmentions before publishing, so I guess that's the place where the receiver checks the source with some antispam list.

EDIT: I researched a bit more, and noticed that there's an extension to Webmentions, called Vouch[0], which may be a bit complicated to bootstrap, and seems like a web-of-trust-ish mechanism to approve of webmentions.

[0] https://indieweb.org/Vouch

Frankly, thanks but no, thanks.

The moment it becomes a legal entity is the moment bureaucracy starts to kick in, big names join and poison the well, internal politics rips stuff apart.

I know this view is a bit extreme and pessimistic, but I've yet to see anything that doesn't go like this. I see no reason indieweb would be the exception.

As it is, the indieweb community is agile enough to be able to fork at a moment's notice if things start to go sour. If money and papers start to get involved, that becomes more difficult.

If anyone from IndieWeb community is reading this thread:

Stop bikeshedding formats and random features (likes, bookmarks, etc) and focus 100% on getting Webmention and rel="in-reply-to" working smoothly and integrated across the blogosphere.

Build on what works, instead of rejecting the entire blogosphere because of some guy's pet project. Forget about bikeshedding microformats and micropub/microsub APIs.

IndieWeb talks a lot about "standards" and interoperability and all this crap but at the end of the day the focus is mostly "let's replace Atom with microformats to do the same things, and argue about how to encode likes and bookmarks." The NIH syndrome regarding replacing Atom/RSS with microformats is incredibly counter-productive.

Start with replies to blog articles, build consensus, build software support, make it a success. THEN move onto replicating Facebook. Webmentions/replies can be done today with Atom/RSS. Just think if all that time spent on microformats was spent building support for webmentions/replies in existing tech stacks!

If you want to get replies working across the blogosphere, try brid.gy which has support for various blogging platforms. If you want to transform atom/rss to microformats, there's unmung.com If you want conversion between lots of formats there's https://granary.io/

You're very welcome to spend the time integrating this with your own site or other existing tech stacks.

I've been blogging on my personal website, https://www.jvt.me for a good few years, but I've found the scope, functionality and interactions increase since joining the IndieWeb.

I've written some posts about my journey which are tagged and can be found at https://www.jvt.me/tags/indieweb/ if you're interested

I'm not a coder, merely an artist with a blog and the interest of thumbing the nose at authority by knowing things.

I don't see a place in the article or the comments here that describes how (or frankly, why) this can be used for the layman (of course, I'm assuming indieweb wants to expand to more folks like mastodon did). Can someone enlighten me?

As for the why, there's a good list of reasons here[0].

As for the how, first of all it depends on the what. The indieweb is a concept like "free software", not a technology like mastodon. You can't just "implement the indieweb". You implement parts of it. And especially you participate in it. A good rundown of fictitious "levels of compliance" can be found here[1].

[0] https://indieweb.org/why

[1] https://indieweb.org/IndieMark

For the "how" part, visiting https://indieweb.org/ is the best start...But, since you used the term "layperson" (as well as mastodon), I would also recommend using a platform that someone has already established (instead of managing your own in the beginning) - such as https://micro.blog/

As to the "Why"...well if you find value in decentralized/federated platforms such as mastodon, you can assume the same value/benefits for a decentralized/federated (full) blogging platform like those used by the IndieWeb folks. Besides...What better way is there to thumb your nose at authority than hosting your own data and blog (a la IndieWeb concepts) where no one (like Facebook or Twitter, etc.) can control you??? ;-)

The thing is you can setup website and host your own website. It doesn't get more independent than that.

I don't think you can build a public park for everyone.

That's not even the main part about the indieweb concept. What really differentiate it from just having your home page is the interaction between indieweb websites. Mainly webmentions, but also profile-sharing across different websites, or using your own website as an authentication method in tandem with third-party identity providers.

Regarding webmentions, webmention.io (receiving) and webmention.app (sending) are excellent. If you prefer to manage your own like me, then you may find this glitch helpful: https://glitch.com/~lean-send-webmentions.

I've also written a complement to webmention.io which it can use as a callback hook to turn webmentions it receives into GitHub issues (great for if you use a static site generator). https://glitch.com/~webmention-io-webhook-to-github-issue

Sad to see that Bridgy lost support for Facebook:

> Facebook is no longer supported. So long, and thanks for all the fish!

> Bridgy included support Facebook from the very beginning, when it launched in January 2012. After the Cambridge Analytica scandal broke, Facebook started limiting its API in a number of ways. Notably, it disabled RSVPing on April 24, 2018, posting on August 1, 2018, and reading other people's comments and likes on May 24, 2018, which killed Bridgy for Facebook entirely.

Just to be very clear, this was ALL Facebook's fault...FB clenched their fist, squeezing their grip ever tighter of their walled garden. Bridgy, all users of Bridgy, as well as all the consumers of the content from these bloggers were the victims of FB's actions. You can have whatever opinions you wish about FB's right to do so...but the content that users freely submitted INTO FB has now been locked off by FB. Make of that what you will...But Bridgy isn't the bad guy here, just the victim.

> Sad to see that Bridgy lost support for Facebook:

That's a weird way to phrase it, it makes it look like it's Bridgy's fault. I would say the lost support from Facebook.

If you are curious to know more, I've collected an array of indieweb info on a site built with an Indieweb enabled Hugo theme, and detailed its features:

https://web-work.tools/indieweb/indigo/features/

As a first step, I'd suggest IndieWeb applies to become a supported project under Software Freedom Conservancy (SFC). SFC provides various services to libre software projects such as fiscal sponsorship, fundraising assistance, legal advice, logistical support for conferences, etc. See https://sfconservancy.org/projects/services/

Reply on news.ycombinator.com