Home Explore Help
Sign In
someonewithpc
/
gnusocial-issues
Watch 1
Star 0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Branch: master
Branches Tags
gnusocial-is...
/
issues
/
notabug.org
/
186

186 7.2 KB
Permalink History Raw

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273 
  1. ---
    2. 

  2. title: Groups
    3. 

  3. author: notabug.org/diogo
    4. 

  4. time: Sat, 18 Jul 2020 12:44:05 UTC
    5. 

  5. status: open
    6. 

  6. ---
    7. 

  7. 

  8. author: notabug.org
    9. 

  9. time: Sat, 18 Jul 2020 12:44:05 UTC
    10. 

  10. content: -----
    11. 

  11. **Aim**: Making GNU social more welcoming and robust for communities. **SoTA**: Federation of groups is being avoided by alternative software and has been proven problematic after the death of big instances like qvitter because one couldn't target groups hosted at qvitter anymore nor contact the whole subscribers list to let them know of the new instance hosting a certain group. **Abstract**: The solution we propose here is to have umbrella/meta groups being logically created in every instance that will collapse groups that are meant to be decentralized into an unit. The structure of these meta/umbrella groups would rely on having a set of known groups with the same name that are meant to be decentralized, e.g.: uri | should_decentralize | unique_name --------|---------------------|------------ A@A | true | A A@ldavg | true | A A@HaP | true | A A@B | false | A In this example set, ldavg would merge the first three entries into one big group named !A. To interact with A@B, one would have to specify this full uri. What about aliases? They now would be created by each individual actor of type person and have to be suffixed with `@alias`. Thus solving any potential ambiguity/collision issue. How are we going to upgrade existing groups from v2 to v3? By default they will be set with should_decentralize=false. An admin can easily change that. If a user tries to target a non-existent group in a message, it will go without mentioning any group. If a meant to be decentralized group is found, an umbrella group will be automatically created and the admin will be the first person to take it over by clicking on a button "Become administrator". A local umbrella group can live without an admin. We can easily have remote actor with moderator permissions in local groups. So moderation of an umbrella group is made by decentralized moderation, moderation permission requests from local admins will be automagically federated.
    12. 

  12. -----
    13. 

  13. 

  14. author: notabug.org
    15. 

  15. time: Sat, 18 Jul 2020 17:22:18 UTC
    16. 

  16. content: -----
    17. 

  17. Sounds good aside from "@aslias __ " if that's what a user has to type. "!__ " was good, why can't we keep that? Suggestion use "!!__ " instead if aliases need a different command. Also, I made most of my Groups original names as 2-3 characters I.e. 1nf with the whole name as "First Nation Freaks" and an alias like "ndns" (how we've taken the silly "Indians" name to be our own).
    18. 

  18. -----
    19. 

  19. 

  20. author: notabug.org
    21. 

  21. time: Sat, 18 Jul 2020 21:01:01 UTC
    22. 

  22. content: -----
    23. 

  23. @thndrbvr I think you misunderstood Diogo, he suggested a suffix, not a prefix, but yes, !!foo as an alias for !bar is a much better solution.
    24. 

  24. -----
    25. 

  25. 

  26. author: notabug.org
    27. 

  27. time: Sun, 19 Jul 2020 01:56:58 UTC
    28. 

  28. content: -----
    29. 

  29. Ohhh I see. Okay. Now, I'm wondering... What happens if an actor of any type has the same name as a group? Will there be any conflicts?
    30. 

  30. -----
    31. 

  31. 

  32. author: notabug.org
    33. 

  33. time: Sun, 19 Jul 2020 09:36:18 UTC
    34. 

  34. content: -----
    35. 

  35. No, that shouldn't be a problem (because one uses @ and the other !)
    36. 

  36. -----
    37. 

  37. 

  38. author: notabug.org
    39. 

  39. time: Sun, 19 Jul 2020 10:30:34 UTC
    40. 

  40. content: -----
    41. 

  41. On the other hand, we would like to have Application, Organization and Service... We are running out of symbols! :')
    42. 

  42. -----
    43. 

  43. 

  44. author: notabug.org
    45. 

  45. time: Sun, 19 Jul 2020 11:24:22 UTC
    46. 

  46. content: -----
    47. 

  47. @diogo aren't those just actors, hence acting like users (i.e. @)
    48. 

  48. -----
    49. 

  49. 

  50. author: notabug.org
    51. 

  51. time: Sun, 19 Jul 2020 11:47:51 UTC
    52. 

  52. content: -----
    53. 

  53. @someonewithpc groups are actors as well, here: https://www.w3.org/TR/activitystreams-vocabulary/#actor-types . Different actor types requires different handling, but I guess the handling for the other three isn't so special as the one required for Groups, we probably don't need a special symbol for them :)
    54. 

  54. -----
    55. 

  55. 

  56. author: notabug.org
    57. 

  57. time: Sun, 19 Jul 2020 15:07:21 UTC
    58. 

  58. content: -----
    59. 

  59. On terminology regarding the group meant to be under an umbrella attribute, rozzin came up with the following on IRC: [rozzin] > GNU social may need a property in the group actor indicating whether it is meant to be decentralized or not. [rozzin] While technically this is an OK-ish application of that the term "decentralized" because the context, at least if the reader is paying attention, significantly narrows the set of possible specific meanings.... But I think the a better term is probably... "replicated"? [diogo] Actually... we replicate centralized groups, we cache them; I would say that the groups as we have them now are being replicated, while this would somehow decentralize them [diogo] If I create a group in ldavg, ldavg is the authority for that group [diogo] the umbrella groups would be sharing the authority among the various involved instances [diogo] For my account, the authority is ldavg, and my posts are replicated among other instances [diogo] but maybe I messing terms up tho, this is how I'm interpreting it at the moment. [rozzin] diogo: "multimastering"? https://en.m.wikipedia.org/wiki/Multi-master_replication [rozzin] https://en.m.wikipedia.org/wiki/Multi-master_bus [diogo] Yeah, sounds like a better term, let me add this to the issue... [rozzin] diogo: "decentralized" really is a pretty generalized term that requires clarification either from context or use of more specific terms; "GNU social (as a whole) is a decentralized social system" is accurate without specifying/clarifying that "GNU social is decentralized specifically via federation"; and there are other systems that are"decentralized" to the same *degree* as GNU social but not in the same *way*....
    60. 

  60. -----
    61. 

  61. 

  62. author: notabug.org
    63. 

  63. time: Sun, 19 Jul 2020 15:10:25 UTC
    64. 

  64. content: -----
    65. 

  65. This issue was shared for implementation-related discussion on https://socialhub.activitypub.rocks/t/groups-implementation/591/55?u=diogo and https://git.pleroma.social/pleroma/pleroma-meta/-/issues/14
    66. 

  66. -----
    67. 

  67. 

  68. author: notabug.org
    69. 

  69. time: Sun, 19 Jul 2020 18:28:37 UTC
    70. 

  70. content: -----
    71. 

  71. Two implementation solutions were considered in IRC, one that tries to mimic exactly what was conceptualized on the opening of this issue, and one that tries to change less proposed by rozzin. rozzin proposes federating the full subscribers list to every instance, when the authority instance of a group dies, the one with more local subscribers (as suggested by @aab) takes over if the "should_decentralize" flag of that group was set to true. Every other instance would know this criteria and act accordingly. Users don't have to know the `@authority_instance` as that could be omitted for groups with such new attribute set to true. a more true implementation to the concept would rely on always addressing all groups instead of an authority, i.e., for the table above, an activity would address `@A`, `@ldavg` and `@HaP` as no-one was more authority than no-one. Also, instead of federating a full subscriber list, we would probably want to federate a list of known hosts holding this group. We can't be sure of anything when we have no authority (i.e., we don't have a sure way of knowing every instance involved). But with rozzin's solution, the authority will always be "all-knowing" and thus we have a source of trust. I think rozzin's solution is true to the way these protocols usually work and not hard of implementing.
    72. 

  72. -----
    73. 

  73.