Salta al contenuto
Citiverse è uno spazio aperto a tutte le comunità. Se vuoi aprire un gruppo locale o una sezione per la tua organizzazione, puoi contattare gli amministratori: pagina dei contatti.

I've been using #ActivityPub for so long that it wasn't until I spoke to an #ATProto -using friend that I realized there are a lot of issues we need to fix to make it easier for mass-adoption.

General Discussion
28 7 18
  • scritto ultima modifica di
    #1

    I've been using for so long that it wasn't until I spoke to an -using friend that I realized there are a lot of issues we need to fix to make it easier for mass-adoption.

    (And yes, mass adoption is important. Whatever is adopted at large becomes something of a social imposition, a necessity to survive in the world...so I'd rather we adopt truly decentralized platforms rather than faux decentralized ones.)

    1/

  • I've been using for so long that it wasn't until I spoke to an -using friend that I realized there are a lot of issues we need to fix to make it easier for mass-adoption.

    (And yes, mass adoption is important. Whatever is adopted at large becomes something of a social imposition, a necessity to survive in the world...so I'd rather we adopt truly decentralized platforms rather than faux decentralized ones.)

    1/

    scritto ultima modifica di
    #2

    Small issues:
    1. A big server connecting to a small one for the first time can overload it. (Can't confirm.)
    2. Searching for usernames can be slow. (Not IME)
    3. Editing posts doesn't always update them on other servers.

    Big problems
    1. You need a separate account for each ActivityPub service.
    2. Native apps can't open links directly - need to copy-paste into the search bar.
    3. Apps usually don't show the real like/boost count - only the ones from your own server.

    2/

  • Small issues:
    1. A big server connecting to a small one for the first time can overload it. (Can't confirm.)
    2. Searching for usernames can be slow. (Not IME)
    3. Editing posts doesn't always update them on other servers.

    Big problems
    1. You need a separate account for each ActivityPub service.
    2. Native apps can't open links directly - need to copy-paste into the search bar.
    3. Apps usually don't show the real like/boost count - only the ones from your own server.

    2/

    scritto ultima modifica di
    #3

    4. Profiles of users on "new" servers can look empty until the initial fetch.
    5. Server defederation can prevent legitimate users from communicating. Users should be able to override server blocks for specific users at a personal level. (This is already possible with certain kinds of blocks, but servers often use the highest-power block which doesn't let this happen.) Server blocks should be clearly communicated to users within the clients.
    6. Moving servers is lossy. *stares at *

    3/

  • 4. Profiles of users on "new" servers can look empty until the initial fetch.
    5. Server defederation can prevent legitimate users from communicating. Users should be able to override server blocks for specific users at a personal level. (This is already possible with certain kinds of blocks, but servers often use the highest-power block which doesn't let this happen.) Server blocks should be clearly communicated to users within the clients.
    6. Moving servers is lossy. *stares at *

    3/

    scritto ultima modifica di
    #4

    @contrapunctus

    absoluty. its collective punishment of all instance users. there is a solutiin to this and that is peer to peer fediverse

  • 4. Profiles of users on "new" servers can look empty until the initial fetch.
    5. Server defederation can prevent legitimate users from communicating. Users should be able to override server blocks for specific users at a personal level. (This is already possible with certain kinds of blocks, but servers often use the highest-power block which doesn't let this happen.) Server blocks should be clearly communicated to users within the clients.
    6. Moving servers is lossy. *stares at *

    3/

    scritto ultima modifica di
    #5

    @contrapunctus 4 opens up server admins to legal liability. Hard no.

  • @contrapunctus 4 opens up server admins to legal liability. Hard no.

    scritto ultima modifica di
    #6

    @navi We seriously need to figure out a proper solution to that. Here's my actual Fedi story -
    1. I try en.osm.town, follow many interesting people, realize I would like some more features (emoji reactions, Markdown, etc) and a better character limit.
    2. I join fe.disroot.org, enjoy the Akkoma experience...but I can't follow a whole bunch of friends because they're on hachyderm.io. I act as envoy between the admins, but neither agrees to acquiesce to the others' demands.

    1/

  • @navi We seriously need to figure out a proper solution to that. Here's my actual Fedi story -
    1. I try en.osm.town, follow many interesting people, realize I would like some more features (emoji reactions, Markdown, etc) and a better character limit.
    2. I join fe.disroot.org, enjoy the Akkoma experience...but I can't follow a whole bunch of friends because they're on hachyderm.io. I act as envoy between the admins, but neither agrees to acquiesce to the others' demands.

    1/

    scritto ultima modifica di
    #7

    @navi 3. I try transfem.social. Hey, Hachyderm doesn't block it! Nice...except now I can't follow some queer friends on shitpost.trade. And neither server seems to be on the blocklist for the other...wtf 😐

    Users should not need to deal with this crap. On one hand we try to reduce friction in choosing a server, on the other hand we have hugely varying views of the network depending on the server you're on.

    2/

  • @navi We seriously need to figure out a proper solution to that. Here's my actual Fedi story -
    1. I try en.osm.town, follow many interesting people, realize I would like some more features (emoji reactions, Markdown, etc) and a better character limit.
    2. I join fe.disroot.org, enjoy the Akkoma experience...but I can't follow a whole bunch of friends because they're on hachyderm.io. I act as envoy between the admins, but neither agrees to acquiesce to the others' demands.

    1/

    scritto ultima modifica di
    #8

    @contrapunctus @navi *do* we need to 'figure out a proper solution to that'? I feel like there's a bunch of unspoken assumptions in there about what people need or expect. people get banned from bars and other venues too, even if that means that they can no longer meet their friends there, yet this is generally seen as a perfectly reasonable tradeoff for the health of the space as a whole. likewise, no one bar is going to have everyone you might want to talk to, so you go to different places over time.

    the details of the case are slightly different here because there are *two* venues involved, but if you feel that that changes things enough to drop common social conventions, then the argument for that should be made explicit rather than just sort of assumed.

  • @navi 3. I try transfem.social. Hey, Hachyderm doesn't block it! Nice...except now I can't follow some queer friends on shitpost.trade. And neither server seems to be on the blocklist for the other...wtf 😐

    Users should not need to deal with this crap. On one hand we try to reduce friction in choosing a server, on the other hand we have hugely varying views of the network depending on the server you're on.

    2/

    scritto ultima modifica di
    #9

    @navi This is not an issue people face (as often) on email or XMPP, where domains are mainly blocked for sending spam + admin unresponsiveness. I've got like 5 different XMPP accounts on different servers and not one of them has this issue. And obviously the problem doesn't even exist on centralized networks - our biggest competitors.

    3/

  • @contrapunctus @navi *do* we need to 'figure out a proper solution to that'? I feel like there's a bunch of unspoken assumptions in there about what people need or expect. people get banned from bars and other venues too, even if that means that they can no longer meet their friends there, yet this is generally seen as a perfectly reasonable tradeoff for the health of the space as a whole. likewise, no one bar is going to have everyone you might want to talk to, so you go to different places over time.

    the details of the case are slightly different here because there are *two* venues involved, but if you feel that that changes things enough to drop common social conventions, then the argument for that should be made explicit rather than just sort of assumed.

    scritto ultima modifica di
    #10

    @joepie91 Please see the follow-up replies. In short - it created unnecessary friction for users, and it's a problem that doesn't exist on a number of *federated* platforms, let alone on centralized platforms...

  • @joepie91 Please see the follow-up replies. In short - it created unnecessary friction for users, and it's a problem that doesn't exist on a number of *federated* platforms, let alone on centralized platforms...

    scritto ultima modifica di
    #11

    @contrapunctus that is not an argument for why it's different and should deviate from common social conventions. that's an argument for why it's *annoying*, which is also true for being banned from a bar, and which was already integrated into my point.

    something being annoying or creating friction, in and of itself, is not an argument to change that no matter the cost.

  • @contrapunctus that is not an argument for why it's different and should deviate from common social conventions. that's an argument for why it's *annoying*, which is also true for being banned from a bar, and which was already integrated into my point.

    something being annoying or creating friction, in and of itself, is not an argument to change that no matter the cost.

    scritto ultima modifica di
    #12

    @contrapunctus (I also would like to point out that vastly more people use fedi today than have *ever* used XMPP even during its heyday, so I'm not sure what point you're trying to make there by bringing it up - it certainly isn't a federated success story)

  • @contrapunctus (I also would like to point out that vastly more people use fedi today than have *ever* used XMPP even during its heyday, so I'm not sure what point you're trying to make there by bringing it up - it certainly isn't a federated success story)

    scritto ultima modifica di
    #13

    @contrapunctus @joepie91 to make your point more concise: It is not unnecessary friction for the same reason banning Nazis from bars is not unnecessary friction.

  • @navi 3. I try transfem.social. Hey, Hachyderm doesn't block it! Nice...except now I can't follow some queer friends on shitpost.trade. And neither server seems to be on the blocklist for the other...wtf 😐

    Users should not need to deal with this crap. On one hand we try to reduce friction in choosing a server, on the other hand we have hugely varying views of the network depending on the server you're on.

    2/

    scritto ultima modifica di
    #14
    @contrapunctus @navi I think it would improve the situation a lot if the blocks were more transparent, and it wouldn't be a trial and error thing one only figures out after already having an account on the instance.

    The functionality is there but too many admins are too paranoid about that one scraping site ran by right wing assholes that collects instance level block data and puts them in a searchable database, so almost all instances hide that information. Which I had to use a few times for myself when choosing an instance because the actual instance pages refuse to show the information that I need to know whether switching to a particular instance will cut me off from half my mutuals.
  • @contrapunctus @navi I think it would improve the situation a lot if the blocks were more transparent, and it wouldn't be a trial and error thing one only figures out after already having an account on the instance.

    The functionality is there but too many admins are too paranoid about that one scraping site ran by right wing assholes that collects instance level block data and puts them in a searchable database, so almost all instances hide that information. Which I had to use a few times for myself when choosing an instance because the actual instance pages refuse to show the information that I need to know whether switching to a particular instance will cut me off from half my mutuals.
    scritto ultima modifica di
    #15

    @LunaDragofelis @contrapunctus i tried being transparent about blocks and it got a criminal complaint filed against me

  • @LunaDragofelis @contrapunctus i tried being transparent about blocks and it got a criminal complaint filed against me

    scritto ultima modifica di
    #16
    @navi @contrapunctus Would the criminal liability require stating the block reason (libel claim) or is it already too dangerous to state the mere fact that instance xy is blocked at all?
  • @navi @contrapunctus Would the criminal liability require stating the block reason (libel claim) or is it already too dangerous to state the mere fact that instance xy is blocked at all?
    scritto ultima modifica di
    #17

    @LunaDragofelis @contrapunctus it was wrt to block reason. however that also means i can not disclose block reasons to users even if they ask.

  • @contrapunctus (I also would like to point out that vastly more people use fedi today than have *ever* used XMPP even during its heyday, so I'm not sure what point you're trying to make there by bringing it up - it certainly isn't a federated success story)

    scritto ultima modifica di
    #18

    @joepie91 What is your source for the number of XMPP users? 🙂

  • @contrapunctus @navi I think it would improve the situation a lot if the blocks were more transparent, and it wouldn't be a trial and error thing one only figures out after already having an account on the instance.

    The functionality is there but too many admins are too paranoid about that one scraping site ran by right wing assholes that collects instance level block data and puts them in a searchable database, so almost all instances hide that information. Which I had to use a few times for myself when choosing an instance because the actual instance pages refuse to show the information that I need to know whether switching to a particular instance will cut me off from half my mutuals.
    scritto ultima modifica di
    #19

    @LunaDragofelis Indeed! And I had to use that site a few times too 🫠

  • @joepie91 What is your source for the number of XMPP users? 🙂

    scritto ultima modifica di
    #20

    @contrapunctus I was using XMPP back when Google Talk was still federating, and Diaspora was the hot new decentralized social media project. I'm not new to this. and that era pretty much *was* its heyday, and it has not recovered since.

  • 0 Votazioni
    17 Post
    11 Visualizzazioni
    mrfunkedude@beige.partyM
    @coldkennels @ambimist It’s why I host my PeerTube instance in Germany. The US is just bonkers right now.
  • 58 Votazioni
    144 Post
    178 Visualizzazioni
    G
    Okay, what you explained does make sense, but not in the context of a federation event (as far as I understand, which could very well be wrong). If B’s server sends the full response along, then C can see the contents of A’s post even though they’ve been blocked by A. Sure, but this would only be needed if a user needs permission or something to view a post. They don't, a post is (always, afaik?) public. Besides, federation is not on a user level, but on an instance level. It doesn't matter if user A has blocked user B. As long as just one person on user A's instance does not have user B blocked, events and metadata will need to be federated. So, for public federated services, I don't think it makes any sense to use this kind of access control.
  • 5 Votazioni
    79 Post
    90 Visualizzazioni
    V
    A lot of the problems with Lemmy boil down ultimately to overall lack of moderation. Yeah, I would say we are definitely at a "work-in-progress" level, with a ways to go. The recent thread in the Fediverse community praising the devs of many Fediverse platforms is a great example: it became highly toxic, ultimately being locked. I saw the post originally. Going back it looks like FiniteBanjo went to pick a fight. I'm not trying make any judgement on their comments, just that they appear, to me, to wanted to start an argument ("Well, not all of them. Some of them are a stain on this earth."). Not surprised it was locked at that point. ... with the admins themselves literally flinging actual death threats against admins of other instances. My recollection and understanding of that situation was that it was an inferred threat, that, when confronted, was immediately rescinded and that admin stepped down due to their actions. So, I think, it's a bit disingenuous to use that as a negative against them. To me, they responded appropriately when confronted with how their message was taken (clarification that's not how it was intended and then stepping down from their position of authority). I believe soon after the .world admins faked "evidence" that the anarchist admins were really fascists trying to sow discord or something (I don't recall the exact allegation, but I remember the evidence being shown and confirmed to be fake). My recollection is Rimu backed the .world admins even after their evidence had been shown to be faked. I want to say that is when Rimu introduced the instance "silencing" feature, to reduce anarchist influence after his and the .world admins' attempts to expel the anarchists with the faked evidence failed. So there will never be a solution to this step that involves all of us getting onto the same page. Decentralization. There doesn't need to be, in my eyes. I do decry the right of places such as Chapotraphouse to exist, but I do think that they need to be labeled properly, with a warning label ... ... the instance picker (the last time I checked) was very confusing and came nowhere close to explaining what individual users could expect when signing up to an instance. ... as people who jumped through all of the prior hurdles flee this toxic shithole ... On-boarding is a huge gap in my mind. From my view, we basically throw everyone in the deep-end and hope they learn to swim and aren't too concerned with fixing the issue, because we all learned to swim, so why can't they. I could see an on-boarding that quickly explains the structure (like 2 sentences about decentralization/email-analogy and identifying a users name and instance. Then go into a quick questionnaire (for determining best host instance for them) about what kind of posts they want to see (one of those could be a quoted .ml account, to see if the new user wants to see "triad" content). From there some, basic filtering/block list yes/nos (block-list for spam accounts: yes/no, agentic accounts: yes/no, bot accounts: yes/no, etc.) and interested topics (software, cats, art, etc.). I think that would go a long way in helping get an easier and more welcoming environment (may only be fully possible via Pylova features at the moment (block-lists)). Unfortunately, PieFed seems to be continually actively working against this goal now, making the options more opaque rather than transparent - e.g. any PieFed community on an instance that does not explicitly disable the downvote feature (and which ones have done that? how is anyone supposed to know!?) is shadow-censoring contributions offered from many different software platforms (Lemmy, Mbin, nodeBB, Friendica, Mastodon, etc.), without disclosure of that fact. That's a good point I hadn't thought of before. I'm not sure how an instance could keep a user informed without keeping a larger database of community and instance settings. Alternatively, sending that info for each load or interaction the user makes. The larger database sounds much more reasonable, but still daunting and not easily implemented and probably with a significant compute cost. ... whose devs look to me to be tired on working to support new features, especially for PieFed. This isn't surprising to me. Piefed has 20% of the users Lemmy has (and that increase to 20% is relatively recent) and developer generally want to get paid for their work (especially if they don't have a main corporate job). PyLova might be the single best hope the entire Threadiverse has to grow. We’ll see what happens! Yeah, definitely looks to be the brightest hope we have right now. Hopefully, they can keep up a sustainable pace and don't burn out.
  • #Relay #ActivityPub open federated free 🆓

    General Discussion relay activitypub
    2
    0 Votazioni
    2 Post
    40 Visualizzazioni
    julian@activitypub.spaceJ
    @manalejandro@cf-ap.com I don't get this. Of everything you could do with AP, why a relay? And it's not you specifically, even if it's someone else vibe coding something for AP, it's always a relay. I think this is like the third or fourth Activity-Relay AI rewrite I've seen.
  • 0 Votazioni
    1 Post
    12 Visualizzazioni
    Nessuno ha risposto
  • 0 Votazioni
    2 Post
    26 Visualizzazioni
    thenexusofprivacy@gotosocial.thenexus.todayT
    Early results are encouraging: experiences organizing against the surveillance-industrial complex in the ATmosphere and the fediverses -- Part 3 of The Time is Righthttps://thenexusofprivacy.net/early-results-are-encouraging/@general
  • 1 Votazioni
    1 Post
    13 Visualizzazioni
    Nessuno ha risposto
  • 4 Votazioni
    4 Post
    10k Visualizzazioni
    macfranc@poliversity.itM
    @fluffgar eh... 🫠

Citiverse è un progetto che si basa su NodeBB ed è federato! | Categorie federate | Chat | 📱 Installa web app o APK | 🧡 Donazioni | Privacy Policy

Il server utilizzato è quello di Webdock, in Danimarca. Se volete provarlo potete ottenere il 20% di sconto con questo link e noi riceveremo un aiuto sotto forma di credito da usare proprio per mantenere Citiverse.