Fediverse-based decentralised player…
They had funding from NGI NLNet
…technically interesting, but questionable legality on rights and ethical rewards for artists.
It’s a shame NLNet didn’t fund our proposals for community, decentralised streaming (PFCS).
Interesting how this directly correlate yet again to Moxie Marlinspike’s (Moxie Marlinspike >> Blog >> My first impressions of web3) post and particularly to this :
“We’d all have our own web server with our own web site, our own mail server for our own email, our own finger server for our own status messages, our own chargen server for our own character generation. However – and I don’t think this can be emphasized enough – that is not what people want . People do not want to run their own servers.”
And yet again, a proposition for decentralization, where on the first page where they present the concept there is this :
“Starting your own pod requires some system administration skills, but will also give you more independence and control.”
(ie. steep barrier of entry)
“If you’d prefer to have someone else host your pod for you, the following providers offer hosted solutions:”
(ie. not decentralized anymore AND they don’t vouch for the 3rd party offerings they share clearly stating that they can’t garanty the outcome)
What appears to me very clearly in all those endeavours, is the need for a more pragmatic approach to “user control of centralized servers”, ie. rather than a purely decentralized approach, an approach were servers are considered common goods that people should be able to collectively manage. This could take multiple forms (one of which was, I believe, Resonate’s proposal for community / localized streaming, which could look something like what I’m describing) but in my opinion this will definitely not look like Funkwhale because Funkwhale just looks like a useful-ish but seen before tech that doesn’t adress the real problem. Like it’s a nice enough interface (not terrific either though) to basically host stuff in the cloud much like you’d do on your own website or whatever and then share them. And yeah, it absolutely doesn’t take any legal aspects in consideration, probably hiding behind the usual “it’s decentralized ! it’s almost like private usage ! it’s basically just cloud hosting.” trope.
Funkwhale sits in the same niche as Mastodon; it’s entirely all-in on ActivityPub (which is not a protocol which is nearly as transformative or worthwhile as its fanatics seem to think), it requires huge amounts of infrastructure to keep running well, and it has pretty severe community issues which you just kind of have to hope that other people are willing and able to sort out.
The core technology (ActivityPub) isn’t really any better than just running a podcast, and there’s already plenty of platforms for hosting those, both with centralized/pseudo-centralized hosting and with roll-your-own on whatever shared hosting provider you need. A blog with an RSS feed can do everything ActivityPub can, and so many feed readers already have built-in support for podcast attachments. Plus, you can host that on any cheap or free shared hosting.
My suggestion for anyone trying to replicate Funkwhale is to build a really good RSS/Atom subscription engine that’s intended for music, and use IndieWeb protocols like webmention and micropub if you want to support comments. You’ll end up with something that’s just as powerful as Funkwhale without tying people to any specific hosting infrastructure or the need for massive server requirements.
Thanks, very interesting and detailed breakdown, and also welcome!
Hi @fluffy! Welcome, great post! ActivityPub [quote=“fluffy, post:3, topic:2874”]
has pretty severe community issues
[/quote] Yes, identity being one of them!
And decentralisation for it’s own sake is rarely a good idea. Using existing tried and tested commodity services aligned with standards, plus transparent governance is often more effective. …
Yes great idea!
@LLK +1 on Moxie’s ‘heresy aka common sense’ post. Signal shows that a centralised ‘enclave’ solution, with a bit of agility and good governance, can be more efficient and a better defence against threats than a Fediverse-style solution without coherent security or a fancy blockchain with dodgy governance.
What we proposed to do with PFCS was to run a mini instance of a Resonate server locally, with local network browser clients, using shared resources (we teamed up with CoBox, who were working on a DAT protocol solution) This is what we put in for the bid to POINTER. In retrospect @fluffy 's RSS subs engine looks a more elegant solution for offline use and ‘cross-subscription’
…another time maybe! Let’s get the basics of Resonate done first!
RSS/Atom feeds are missing one key component for “cross subscriptions” in having any sort of identity/authentication mechanism built in. However, there’s an ongoing effort in IndieWeb spaces (which I’m a part of) to make that a reality. The core protocol is called IndieAuth Ticket Auth, which is an offshoot of the IndieAuth protocol where it’s a very simple token exchange that takes place between a publisher and a consumer that results in a bearer token that the consumer can use for subsequent authenticated access.
It’s a work in progress and not very many things support it just yet, but I’ve implemented it on the publishing side on my website (to support private/friends-only entries) and there’s a few folks on working on adding it into their feed readers. It shows a heck of a lot of promise, and ends up solving privacy- and authentication-related issues much more elegantly and securely than anything ActivityPub has to offer.
There’s also a few other approaches folks have taken, for example Patreon provides an “authenticated” podcast feed by essentially giving each subscriber their own URL with an embedded access token that’s meant to be kept private. That has some security implications (since it’s all too easy for someone to accidentally share their private feed URL) but it’s at least a workable half-measure that’s already inherently supported by every existing podcast client.
@fluffy this is really interesting! Great work.
Have a look too at our verifiable credentials work on common co-operative membership here
…and here is one of the early open source ‘plugin’ products we are creating
(Demo video links to follow if you are interested!)
Interesting! I’ll ask some of my IndieWeb contacts if they’re familiar with this. It seems a little bit outside of the IndieWeb design philosophy (where the “proof of ownership” is usually implied by control of a web resource, usually a connection being declared via a <link rel> or the like; to IndieWeb, one’s identity is their homepage URL, more or less) but we’re always interested in adding interop.
Like not to go too far into the IndieWeb weeds here but the overarching thing is that it’s “HTML as an API” and any secret-exchange stuff is implementation defined and generally by a bearer auth token, typically granted with an OAuth-style flow; tokens themselves are per-application and opaque.
I think they could work well together… I suppose a VC is a bearer token that’s a package of claims, usually in a context defined by an issuer. The VC can be used to ‘self-issue’ an OIDC token. The clever bits are selective disclosure and verifiability, without having to ping back to an issuer to check ‘is this guy who they say they are and is what they say true?’
Let’s each do some reading up and circle back on this. Thanks!
Exciting conversation, hope we’ll get to have you both on a call I find these discussions enlightening.
