zdunn

> But RSS isn’t the reason why podcasts are popular

I don't understand the relevance of this point. RSS is infrastructure so why would end users need to know about it? They don't know about IP addresses when they type a domain name into a browser, but you wouldn't argue that it isn't mainstream tech.

> Some of the most popular podcast platforms like YouTube and Spotify are completely detached from RSS.

This is a quibble and beside the point, but neither of these platforms have podcasts. I can't subscribe to their audio tracks in a podcast player.

But again, I don't see the releavnce. Some platforms not using RSS doesn't detract from the usage that RSS does have.

> Decentralizing that type of interactivity has only recently been achieved by ActivityPub.

This was not a recent occurence. ActivityPub is descended from a long line of work (Ostatus, pump.io, etc) some of which used Atom. Dave Winer (one of the developers of RSS) is experimenting with building a full social network on top of RSS. Podcasting 2.0 (https://podcasting2.org) is working on adding chat/commenting to podcasts. Your original assertion was that RSS can't be used to build something like TikTok, but there have been multiple projects built with either RSS or a close enough analog that show it can be done

That's only a problem for the engorged advertising industry that's been built up in the past couple decades. Putting ads in an RSS feed is no different than non-algorithmic ads on a webpage or classified sections in newspapers, which worked fine for everybody until targeted advertising was introduced.

Secondly, that just leads back to my first point. The ads (even targeted ads) are already on the final content.

I just can't view this as a failing of RSS. It wasn't intended to help publishers advertise, it was intended to help end users track the sites they wanted to track. I understand these are some of the reasons Google and other publishers disincentivized the usage of RSS but RSS works great for its intended purpose. I want more technology like RSS, not tech that helps publishers exploit us

But RSS did become mainstream; podcasts are a normal part of media now and non-techies seem to have no problem finding and consuming them. They don't have to know about RSS.

There's no reason similar UIs can't exist for text based content. Google Reader, and then G+, had a path to becoming "mainstream outside of techie circles"

There's nothing special about TikTok's user experience. It uses an algorithm that isn't interested in providing a chronological feed, but I don't see why RSS couldn't be used to build something similar. Again, podcasts use it and it works well for that. The discovery aspect happens outside of the scope of RSS, but once you find things you like, RSS works well for tracking them.

The tiktok (or any corporate social media, really) comparison is also a bit odd because they don't need RSS, even if they wanted to provide a chronological feed. The platform hosts the content so it knows when there's new stuff and how to access it to provide to followers. RSS is useful in a decentralized environment where the content could be hosted anywhere and you want to aggregate it

Aren't the ads already on the webpage? If the RSS contains snippets of the pages and I have to navigate to the page to view the article, then I see your ads.

Also, can't the ads be a part of the feed just as nicely as the articles? What's stopping publishers from inserting ads as items in the feed?

Right, you said you're from the UK so that's in line with what I would have expected. My unstated point was that multinyms are intrinsically tied to dialects so there is no absolute list of multinyms

> "e'er" would sound slightly different as it's spoken almost like two syllables, though not quite.

I'm a native English speaker (US). Sometimes when I say "ever"/"never", the 'v' sound drops out. So I end up saying "e'er"/"ne'er" but it sounds like "air"/"nair".

> Further down the list, I've just spotted "taught, taut, tot" and "tot" doesn't belong there.

I pronounce all of these the same

In the United States South, its very common to drop the 'g' at the end of a word ending in '-ing'. barren-bearing can definitely sound the same here.

I'm from South Carolina, USA and I pronounce 'greater' and 'grader' the same. There is a subtle difference and that difference can be more noticeable sometimes, but most of the time I'm saying them the same.

For everything in this list, its incredibly common for these groupings to have the same pronunciation where I live.

I think the acronym thing is related but a separate phenomenon. My guess would be that speakers intuitively think the acronym isn't easily understandable so they add an extra word to clarify it, intentionally or unintentionally duplicating one of the actual words in the acronym.

"pont bridge" sounds like the exact phenomenon though. Does it have a more specific meaning that "bridge"?

> mistranslated horno to "earth oven"

My argument is that it's not a mistranslation. In Spanish, "horno" means any kind of oven. In English, it means specifically an earth oven because when English speakers started using the word, they always used it to mean that kind of oven.

A sibling comment mentioned chai tea. It's the same phenomenon. Chai means any tea in its original language, but in English it means a specific variety and preparation of tea.

English is a bastardized language and has a lot of words borrowed from other languages. But once they're borrowed, they're English words and have their own meaning separate from their original loanword.

When a common word from another language is borrowed into English, it tends to take on a more specific meaning. Most native English speakers wouldn't use "salsa" to describe any other sauce. Horno oven sounds perfectly reasonable in English to specifically describe an earth oven in that style, not the common household appliance.

EDIT: Probably the reason this happens is that most English speakers wouldn't be familiar with the foreign word, so the speaker uses it as a modifier to the standard English word. The listener doesn't need to know anything specific about the foreign word in that case and can just assume it's a type of the common item.

> just make transit more attractive, not make driving less attractive

If ppl drive more than use transit, they won't support improvements to transit. This is the first step to improving transit. Make driving less attractive, more ppl use transit, complain about its shortcomings, and then fixes get implemented.

I also don't see why we shouldn't make driving less attractive. As the grandparent comment said, drivers should be the ones paying for the problems caused by drivers, not residents.

> Also, though the author mentions annotations, I don't see how they intend to implement them.

It's discussed at the very end of section 8 and all of section 9 that interactive functionality would use web components.

> The basic thing I am saying is that if you call it a web browser and use the same core protocols etc., you have a practically infinite (for an individual) set of requirements to implement and will never be truly compatible

But what the parent is saying is you don't have to be compatible with 100% of websites. If you build a browser with good HTML/CSS/Javascript handling, you'll be compatible with the large majority of the web. Yes, there are other specs that are in use by a tiny portion of the web. But your browser can still exist if it doesn't support them. Users of that website will know or find out that they can't use your browser for that, but for every other user that browser could be exactly what they need.

> without having to worry about a fuzzy and ever-expanding definition of what you have to support.

It's only ever-expanding if you're trying to keep up with the Jones's. You can define a subset of the web you want to support and build a clean, small browser that supports that.

Aren't you the developer of Smithereen (a fediverse server)? Nearly every other fediverse software has a web interface that can act as a PWA. I launch lemmy.ml and kbin.social as standalone PWAs from my homescreen. My pleroma instance also has some PWA features (though not standalone display mode). I don't use Mastodon, but @[email protected] did some amazing work years ago to make it a really fast and responsive PWA (which has since been undone ).

It's ok if you don't like to use PWAs but that doesn't mean nobody does or that they're worthless.

I asked for it, and a lot of other ppl did too. These are great features and removing them would cause more than 1% of websites to lose some functionality.

But, importantly, they shouldn't lose their core functionality (if they're written well) because that's the "Progressive" part of PWA. If you don't use the feature or your browser doesn't support it, the website should still have basic functionality. One of the big ideas behind PWAs is "progressive enhancement", where you layer on features that may not be supported everywhere but add value when they are supported.

And a progressively built browser that doesn't implement every spec goes hand-in-hand with that. I think having more under-featured browsers like that would push webdevs into caring more about progressive enhancement.

I've found https://tiddly.packett.cool/ is great on desktop and mobile

Discoverability is a little better since Pleroma exposes the public timelines for non-logged in users (though the admin can disable that). I'm not sure about search.

The repos they linked are just for the clients. I think the server software would be way more interesting, but it's also their secret sauce so it unlikely they'll open source that.

I'm with you that allowing the clients to connect to a different sync server (gpodder, etc) would be a great feature. Though, again, I don't see that happening because it would cut into their subscription service.

Except in situations exactly like this one. A user shouldn't have to worry about local vs remote videos if they want to share the link outside the fediverse and someone clicking that link definitely shouldn't have to know about instances, federation, etc to be able to watch the video. Clicking the link should take them to a watchable video; if for some reason, it's not available for watching on the instance, it should use a http redirect instead of loading an intermediary page

Right, but that doesn't mean the server can't support other post types or leave complex UI to other clients. Each server could fallback to displaying a link to an external post at a bare minimum, or display whatever the `content` field. I'm just arguing that the C2S is perfectly viable and would make the fediverse so much richer and more usable. Using the Masto API to federate only specific types with specific software is limiting the fediverse.

> The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.

That's subjective and exactly the type of thing that could be handled in a client. In both cases you're displaying the exact same data. A microblogging thread may be displayed as a flat list, but it's still a tree like a link aggregator thread.

> I meant a Facebook-style social network. So a platform to post what are essentially blog posts. In ActivityPub, that would be the Article type, which, according to the spec, has no semantic difference from Note. An Article could be created as a Note and vice versa with no semantic difference or loss of data. Just like above, the data is the same and the only distinction is the visual presentation of it.

You could ask around the indieweb irc, https://chat.indieweb.org/ Some of the people there have messed around with syndicating to ActivityPub. I think one of them maintains a Wordpress activitypub plugin

You could also check out Pleroma; Mastodon isnt the only microblogging software on the fediverse

https://pleroma.social/#featured-instances https://fediverse.party/en/pleroma/

That's the basis for https://indieweb.org which i think is a much better solution than ActivityPub. See micro.blog if you want an example of a productized form of those ideas

> You can't shove Reddit into Twitter UX and expect something nice to come out, no matter how hard you try.

Why not? it's text; you could make the same exact post on reddit and twitter (barring the length, which could be truncated in a federated context). Link aggregation is basically just microblogging with the extra constraint that the initial post has to have a link.

> Smithereen is a social network

What does this mean? Every other platform you mentioned are social networks. On all of these platforms, a user posts text or media posts. Displaying them in a different UI doesn't make them radically different.

But you can't post a video to Peertube or start a thread on Lemmy. There's a level of interoperability that was envisioned for the fediverse that we're missing right now. If you post a video, Peertube users won't see it despite being the fediverse's main video software. If you post a link with your commentary, Lemmy users won't see it despite being link sharing software.

The microblogging platforms ingest most types of posts from the other activitypub softwares, but the other platforms don't ingest posts from the (micro)blogging platforms. With the client-to-server API, the other platforms would just be clients on top of your Friendica account.

> I am not sure why the ecosystem went this way

Because when activitypub was still getting off the ground, mastodon built their own client api. A lot of excited people built apps for mastodon so pleroma, and then others, started building Masto API support so that their instances could use mastodon clients. Now the Masto API is the de facto client api.

I super agree with you, using the client-to-server protocol so that we could have one account would be the best situation. I've been arguing that on the fediverse for a while, but all the developers in the space seem to think the client-to-server protocol isn't useful enough so you would have to fallback to a custom API for the missing pieces anyway so you might as well use the API everyone's already using.

https://indieweb.xyz is a reddit-like link aggregator and https://www.indieforums.net/ is a forum for independent blogs. Neither is curated since theyre user submitted content, but still might be of interest to you. I think the "indie" in both of these is less directly about being IndieWeb and more about being small, independent blogs, so hopefully more likely to be "No news or tweets or blurbs, just good high quality writings"

You're right, my bad. I was getting ahead of my self. The JS fallback covers older, non-evergreen browsers and the HTML fallback covers everything (including the described issue)