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?

There’s a reason why Twitter, Facebook, and Reddit are separate sites, and why none have tried to implement the UI or feature set of the other.

Yes, the reason is that corporations can not profit from an unsiloed web of data, so they all created their own walled gardens and successfully fooled users into believing that the UI needs to be tightly coupled with the data they host.

having 3 different tabs open with the 3 different kinds of content/conversations just makes a lot more sense to me.

What would be stopping us from having these tabs using the same data from the social graph?

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.

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.

no it doesn't. most clients open third-party links in the actual browser. interstellar has a setting for that.

i'm saying that the functionality you're describing is already perfectly encapsulated by a normal browser, and what you want is that, but limited to a handful of sites.

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.

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.

Why don’t the highest use rate clients for Fediverse services look like standard browsers?

they don't? i feel like they pretty much do, considering they're all web pages.

do you have a central log of notifications you can access via your desktop?

every desktop environment i've used in the past 10 years has this, it's basically been the default from windows 8 forward. GNOME puts them front and center in a dropdown in the middle, windows and deepin has a sidebar, KDE pops out a whole window for them.

basically the crux of it is what you want to do with your notifications. for me, a notification is an indicator that someone wants something, so the action it should perform is bring me to whoever it is. if that's all you need, then you're already there because every client i've used already has notification settings that allow you to filter stuff.

the reason i'm asking questions is that you're all over the stack here. you're talking about a user chrome, then you're talking about consolidating messages, then about notification filters. i think it can all coalesce into something if you start from the capabilities of activitypub itself. it's basically a messaging system at its core, with clients all deciding how to handle the contents of each message. i've long thought that neither twitterlikes or redditlikes actually play to the strength of the protocol, and that activitypub needs some sort of killer app to really shine. if you think you have something, you should let it form into a coherent idea and present it.

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.

hm, i think there's some confusion regarding AP here. there's no "deciding where things should go"; every frontend can "see" every type of post, even if the format is off. what you're describing by is essentially how it already works, no multiple accounts needed. the frontend just needs to decide how to handle it. for lemmy-to-masto the handling is pretty basic, you can see it by going to a mastodon server and searching for your lemmy account (formatted as @yourname@yoursite.blah).

for the "gossip" thing, every server already publishes every new thing. it's up to other servers to decide how to handle it.

regarding the automated tagging system, i actually had a similar idea recently. i think a big flaw with lemmy/mbin/piefed is the keeping of communities from reddit; if the already extant tags were used instead, the cross-posting problem would go away completely since comments would be attached to posts rather than communities.

anyway: it would not be difficult to just use words in a post to assign it tags, but i question the usefulness of doing that. some sort of analysis would help, as you say, but then we're introducing nondeterministic behaviour. there is definitely a discoverability problem on fedi, and something like this could definitely help with some polish.

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).

the formatting is up to the client that displays the content, interestingly enough. AP just has a "message type" fields and different clients care about different types.

i'm not really sure what that gossip method achieves. surely if it's just post metadata we're talking a hundred bytes at most. running it separate from the main feed seems like it would just bork every single AP client that tries to use content published by this hypothetical one.

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.

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

i don't understand this assertion at all. the post is the post. surely we want to classify the post based on the content of the post? tags are contained in posts. your client can just add the relevant info before sending it. figure out potential categories locally, query the server for which of them are popular, and either pick one or have the user select one.

The difference is that I'm talking about the automation creating completely new groupings, most akin to a community on Lemmy, that coordinated across multiple users, in my mind "simultaneously" with the user still agreeing to opt in to inclusion in that group.

There is an alternative way to do this, which would be that the automation groups the posts after posting, however there is a question there about opt-in, will users want to opt existing posts in after the fact?

One way that definitely would be easiest to implement would be if these groupings are essentially threads with a single piece of content as the "start" / "seed" of the thread and the other posts relating to that thread. Regarding opt-in for that I suppose it could be as easy as enabling/disabling "thread seeding"

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?

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? solidproject.org/

I think Solid had some interesting ideas, but was ruined by Linked Data.
ActivityPub has a chance of evolving into something like Solid, but better.

Actually, I am already using a single account for interacting with most Fediverse apps. Aren't you on Mbin? I thought it also can interact with blogs, forums and everything in between

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.

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.

On the first point, propagation happens passively too. For example, if someone follows me on Mastodon, this reply will be pulled to his/her feed as a microblogging post, and will be discoverable on any feeds my account later appears. I remember also testing around between Lemmy and Mbin how liking/upvoting works, and doing that on Lemmy while the Mbin account followed it also showed posts previously not on my Mbin instance.

Similarly, Mbin (and dunno about Lemmy but I'd imagine it's the same) pulls Peertube channels as magazines/communities, and iirc Peertube channels can also be followed as users on microblogging platforms, and in both cases their video uploads automatically appear on the respective text feeds.

And about the second point, I agree, but that's also why I suggest recommending major platforms. For example, Lemmy.World and Mastodon.Social are likely to have far more publications being posted on or propagated to than Mbin or PieFed instances, since the former two are around for much longer, and not actively trying to be toxic (at least from what I can observe).

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, 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.