Thanks, this is definitely the direction I was imagining, though it takes the tac of trying to be a primary browser with Fediverse features, rather than a Fediverse dedicated browser instance, so they will be forced to sacrifice UI streamlining for website-centric UI.
What don’t you like about the idea of you dont mind explaining?
Aha, but you see my proposal specifically keeps the web clients for the specific content streams up to the user rather than baking them in. I like M.Bin so thats what I use for threads and microblogs, so thats what I would select as my service for that content within the browser.
What I want is a unified inbox, with a move from each notification over to the webclient I choose to interact with the content. To be more specific I want a text-only inbox, but I want it to include headlines/captions/descriptions for multimedia content so I can have my Peertube, Pixelfed, Loops, Threads, Microblogs and whatever else all accessible from a single point of contact.
I definitely agree on the portable account point, it always reminds me of Solid the private data project by Sir Tim Berners-Lee. Seems like ATProtocol may have been influenced by it?
Looking great! I’d love to add this to my fedi-toolkit
[Edit: I see the problem, even with a self-hosted instance of 1, when you comment on posts in other instances that data is no longer held on your server, so you don’t own it and can’t control it directly, is that right?]
So as I understand it the big “advantage” of ATProtocol is the account portability via DID, however this is at the sacrifice of actually hosting an ATProtocol being extremely data heavy.
This has made me very curious about self-hosting ActivityPub (meaning an instance of 1 user), it would seem like focusing development on a client that makes it as close to as easy to self-host an instance as it is to join one would solve the issue of accountability portability, as you literally own all the data and rights when you self host. The Major challenge I see there is security, where experienced admins for larger instances should have some level of cybersecuroty expertise while the average use may have little to none. But then focusing group effort on auto-updating the client and the default settings of the client to maximize security would solve that issue it would seem?
So what am I missing? Other than hosting costs, what else is deferring a self-hosted-first development approach for the Fediverse?
Is it actually that AP development fundamentally believe moderation should be handled at the admin/instance level, and self-hosting makes moderation more difficult and less directly authority based?
Publicly shared blacklists and whitelists would seem the natural fit for a self-hosted-first network, akin to adblock and horizontal.
Actually there is a legal definition, a Public Benefit Corporation has statutes in its articles of incorporation which legally commit the company to pursue a set purpose which supersedes the fiduciary responsibility of the corporation to shareholders. This is important because it provides some degree of legal protection from activist shareholders suing the company for making spending or policy decisions which don’t directly maximize shareholder value. The body of law around this issue is still relatively murky, but some defense is better than none at all.
For example, shareholders could attempt to sue BlueSky into increasing advertising placement or data sales functionality intothe core platform to increase company revenues, but if that is at odds with their stated public benefit purpose the legal team for BluSky would have grounds to attempt to dismiss the suit on the grounds that the shareholders purchase the shares under the explicit understanding that these functions would be subordinated to the public benefit goals of the platform.
Our party uses Roll20, but mostly due to sunk cost of content, it works fine.
We tried Foundry VTT but from.time to time there were connectivity issues. I’d say be sure your connection is very stable and you understand how to work your network/firewall/proxy settings before hard committing to Foundry. That said, it is a pretty nice system overall.
Now a couple of options you should be aware of are AboveVTT which is an extension that converts D&D Beyond into a full VTT people really like, good if you already rely on D&D Beyond.
Then there is the FOSS option MapTool, which is a full featured self-host VTT akin to Foundry, but totally free. If you like this kind of projected don’t mind community built documentation, this is a legitimate contender.
haven’t come across them, it figures I wasn’t the first to think of it. So far from the other comment I have found the .makeup instance, which seems to be doing what I’ve been thinking but is a bit odd in its interaction with my home instance
hmmm… if the search on one of these (Instagram) resolves a username but my client (m.bin on kbin.earth via Interstellar app) can’t locate it does that mean my instance has blocked kilogram.makeup?
aha! of course I wouldnt be the first one to think of it.
I have two challenges to this take.
Firstly, the theory that cross-propagation of media will lead to growth across multiple platforms starting with one as the “mainline” to recommend to new entrants heavily relies on Superusers who not only use multiple platforms for content discovery, but also then take the additional step to cross-post that media from one silo into the other, for example posting a peertube link into a miroblog post. For most people they will instead interact with the content in each silo, commenting on or favoriting the peertube post within the peertube client and leaving it at that.
Secondly is the attention economy factor and platform inertia. Essentially social media platforms have successfully commodified/colonized a growing percentage of total attention hours for average users, and when interacting with content most users are passive consumers for a substantial percentage of the total content they are served. When entering a new platform, for it to serve as a viable alternative it must serve up an amount of content that allows them to both use the platform for an appreciable percentage of their total media consumption (otherwise the ratio of times checking the platform to reward for the check drops below acceptability) and provide them with a level of engagement that provides platform satisfaction, which typically starts close to where they were on average with the other platforms they use. Then you have this issue of content-fit which is a whole different issue to address, which we will leave aside for the most oart but it is worth pointing out majorly impacts the number of interactions a user puts in to the content as well as overall satisfaction.
Unifying the inbox reduces one of the barriers to wider adoption by improving the ratio of number of times the platform is checked to the amount of content available for interaction, thereby making the fediverse a more likely source of overall content to be maintained in the user’s set if options. Each platform individually will struggle with this until adoption passes a certain threshold. Each one individually feels “empty” to users when compared to their usual, which is a turn off for both consumers and creators, while in aggregate the picture is much better.