Yes, the automation datastream would need to be segregated, and probably ephemeral.

The point is that if you want posts to spontaneously coalesce with some kind of shared Metadata, you want the ML content analysis information of the post to go out before the actual post is published so the final post Metadata can include the “group” tag or whatever you want to call it.

Alternately you could do it after the fact by editing the post, but that seems like there would probably be some degree of chicken and egg scenario.

All of this could be done by the client completely independent of post metadata of course, but then how do you make the relation of the posts to each other consistent between multiple users? Is that even a desireable/necessary goal is a question I suppose.

Regarding “where content should go”, I mean like which community to post a lemmy post in, or which account to post to if a person manages multiple topical accounts (or accounts in different instances specialized for specific services), or whether to format it for loops vs peertube for video, etc.

Gossip wise, I’m imagining compressed data posted in a format only intended to be ready by the automation systems which happens before the suggestions are made, so that the suggestions can include dynamicly grouping content before publication by appending the relevant metadata/format (like posting in a lemmy community).

I’m going to have to dive into push notification handling, I basically minimize the use of push notifications at my desktop level to only push work related content, and use the notification system of the clients to handle the “recreational” content which leaves me checking lots of platforms separately.

It makes sense that there should be the ability to create separate profiles with different filters and behaviors at the push notification manager level, I just haven’t thought to look into it before.

Regarding killer apps for ActivityPub, and unified clients, I have a second idea which I didn’t want to cloud this thread with that seems somewhat inevitable that will require a central portal with access to all services (and accounts?). That is a single publishing UI where the user creates/uploads any piece of content and then it suggests what venue/service/account to publish it on and related add-ons like hash tags, etc. With the Fediverse the APIs are open and multiplatform publishing clients (like FediPlan) already exist, so a level of light ML/AI for publication seems inevitable.

The next level of this, and what could be a “Killer App” is spontaneously generated affinity grouping via content aware publishing, meaning that the publishing client not only suggests where the posts should go, but also has a metalayer where the publishing clients instances “gossip” about the content being published and then create brand new “spontaneous” venues to publish that content in alongside other similar content being published by other users. Suddenly your text post about a super-niche interest or problem is pooled with posts by other users on the same topic, and bam you have a relevant discussion group of commenters/posters.

Problems of course arrise from this re:advertisers/promoters as well as unsavory/harmful mutual interests, but to be honest I think this is more of an inevitability than a possibility, so getting ahead to architect it in a way that minimizes potential abuse before the corpos get on it is probably a good idea.

I use mbin for threads and microblogs, but it is missing some multimedia support. Someone told me that it can follow peertube accounts, but it only populates text, so I’m going to check that out next. Maybe it will evolve/build steam fast enough to really become the does-it-all platform with tons of devs putting in the necessary work, but right now I don’t think it qualifies.

As a side note, what I’m talking about would be an alternative approach for a specific reason, dedicated UIs for specific content streams can be chosen by the user rather than baked in to the platform. For some people, this modular approach is going to be better.

Yes, basically a browser plugin and a skin would do it. Someone just commented that push notifications at the desktop level handle this for them, and that was an aha moment. The extension could just be a push notification log woth the ability to filter for a group of designated sources.

Why don’t the highest use rate clients for Fediverse services look like standard browsers? There is a level of pure aesthetic sensibility at play.

I’m interested in what you mean by your desktop handling your notifications, do you have a central log of notifications you can access via your desktop?

This is actually a pretty great angle I hadn’t fully thought out, most clients do push notifications, so is what I’m really talking about just a push notification log with the ability to filter for a set of designated sources? That would definitely handle a hefty chunk of what I’m getting at, the rest is basically just a browser skin and some extensions.

Yes, thank you.

The core of my proposal is to minimize the dev burden of a unified platform by utilizing the siloed web clients for content interaction while centralizing notifications/inbox.

This should please both camps because the platform people will just keep doing the same thing they have been doing, while the browser folks get a single point of interaction with notifications but multiplatform capability on content interaction/graph navigation.

This is an issue of reading comprehension, I’m talking about a browser with a UI customized to fit Fediverse needs first and websites second, plus a service embedded in the browser to pull unification from each service into a single stream.

Preserving website functionality is still essential to the browser, because both the fediverse clients and the links posted on them should in my opinion be opened in that same browser by default (or set to open a different browser if the user prefers).

Im just talking about UI, no one said anything about blocking websites. Just because the address bar doesnt live onscreen by default doesn’t mean it should be eliminated entirely.

Yes, this is my point exactly. I want the 3 tabs, AND I want a unified inbox that opens those tabs when I interact with a relevant notification. Seems like there are some projects heading this direction.

Ideally I dont want a new tab to open for every time I click on a different notification of the same type, just reuse the existing client tab that is open.

hmmmm interesting, a lot of this is news to me. I’ll have to try and pull in some peertube accounts, I have never seen any posts showing them.

I also admit I dont follow that many individual accounts, but I don’t follow some and I’ve never seen a comment come through as a notification. I’ll try following you and see if that changes.

Yes, we all want that for sure, and I’m definitely not convinced the ATProtocol solution is it.

Ever hear of Solid by Tim Berners-Lee? It was an early approach to this single account for private data concept, seems like it might still be in development these many years later? https://solidproject.org/

I do use M.Bin, but I want Peertube, Pixelfed, Looped, etc. to feed notifications into my inbox, and I dont want the burden of development of that UI to fall on m.bin devs when they should probably just focus on continuing to optimize text content functions. Also I think it is totally possible someone will come out with something better than m.bin and it would be nice if that was just plug and play into my inbox rather than requiring a full migration.

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.

Awesome! Thanks!

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?

Who said that? The browser still needs to be a browser in order to open links in posts. Similar to how Interstellar the client I’m using right now brings up a browser window when I click a link.

Yes, what I’m getting at is a way to create a notifications/inbox client that pulls from all the above stated API’s but does not attempt to push any content to them, instead switching the user over to their preferred webclient when content interaction begins.

Kind of like how an email client shows a title/headline, sender, and Metadata for each post but then expands a rich text / markup environment when you open the email. Or how some minimal RSS readers just pull headlines and a quick summary of each post but push you over to the original website when you click through to read the full post.

I just want one place to see who has posted on what, and then use the front ends specialized for each piece of content to actually interact.

I suppose there could be a side development to this, which would be the ability to associate accounts across multiple services and then filter only for them, for example if you know someone who posts on lemmy, Mastodon, peertube, Pixelfed, and loops, you could view all their posts of the day in one place. Or a team you are a part of. Anyway, once you can pull multiple services into one inbox the data sort potential is an obvious added benefit.

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

Sounds a bit like Scuttlebutt