Forgefriends monthly update, February 21st 2022, 5pm-6pm UTC+1

Events
#1

This monthly meeting is a conversation about what happened in the forgefriends project since the last meeting, as described in the February 2022 blog post.

Videoconference at https://meet.jit.si//ForgeFriendsCommunityMeetup

Recording is here

Short reminder about the Code of Conduct

It starts with 5 minutes presentations (maximum 6) about what was done since the last meeting followed by a 5 minutes free discussion on various topics. Everyone is invited to make a presentation, as long as something concrete happened and exclusively about activities conducted in public. Each presentation must be prepared (improvisation does not make for a useful presentation) and associated with URLs where participants will find evidences about the activities.

Setting the date for the next meeting

Any date during the next month is suitable. For instance the July meeting may be on the 20th and the August meeting on the 2nd, as long as at least two person are available to participate.

Presentations

Discussion topics

Topics for next meetings

  • …

Simultaneous translation technical notes

  • Everyone is connected to the same room
  • Before starting the meeting participants that will benefit from simultaneous translation will say so
  • Everyone lower the volume of the participants that will benefit from simultaneous translation to be audible but not understandable (less than 20%)
  • The that will benefit from simultaneous translation lower the volume of the translator to be audible but not understandable (less than 20%)

This short video is a visual aid to explain how to lower the voice of a participant to the conference for simultaneous translation purposes. In this short video one person starts to speak Hindi and a few seconds later another one starts translating. The two voices overlap which is distracting. The listener prefers English and lowers the voice of the person speaking Hindi using the slider that shows in the menu that appears when clicking on the three dots next to the speaker avatar.

image

When the translator speaks, everyone hears a faint voice from the participant being translated and hears the translation instead. The participant being translated faintly hears the translator but is not disturbed because the volume is too low for them to understand.

1 Like
#2
1 Like
#3

I’ll see if I can attend this one, I want to get back into this now that work has slowed down a little bit.

2 Likes
#4

Tip: Add a nice image in top of the first post. This will then become the link preview OpenGraph image when sharing the URL.

2 Likes
#5
2 Likes
#6

Thanks for recording this webinar @dachary. It was a pity I couldn’t be present. Especially some topics at the beginning were particularly interesting to me, so I have more or less (though not 100% literally) transcribed them. I’ll include the text below, as your explanation about the working of forgefriends federation sync was very clarifying to me:

Forgefriends community meetup (2022-02-21)

LD = LoĂŻc Dachary
KN = KN4CK3R (Janis)

LD: Struggles with Federation. Too much focus on the protocol, but what should it do? Some think AP should be the only protocol used. How to maintain DB state? Then I figured AP is for notifications. You need 2 protocols, one to maintain state and the other to maintain notifications. And it doesn’t matter if these notifications get lost. AP offers no message delivery guarantee. Something for reliable state management is required. This is not how people talk about AP saying “But it conveys data”. What is you lose a message, say a Patch, do you have a reply mechanism. Can you determine the sequence of messages? You don’t have that in AP. You have a means to convey data, but no way to convey a consistent set of data. This is a difficult problem, but you don’t need to solve this problem. Some people may try, but when federating forges we do not need to solve that problem. What I do now in Gitea is I dump the migration format in Gitea in files in a repostiory and then I use git to move the data from one forge to another. And then when there’s a commit or an issue that is created I can send an AP message to the other forge. The other forge gets it, and what they do, they do not assume they received all the notifications before that. They first sync the data that is in the git repository and then they focus on acting on the issue creation message that they just received, so really the commits that are just conveyed - the AP notification is more a way to say “Oh, wake up” - and if you miss notifications, then no worries because you can pull from the forge from which you receive notification.

KN: Do you think git is the right protocol to sync data?

LD: Well, it has open qualities that a protocol needs, plus it is available on every forge.

KN: Deleting something is difficult in git

LD: Yes. Oh, but you get the history. It doesn’t matter. You delete it. You have the working tree. I did not mean… Like you dump the files in a working tree, you commit that in the working tree. You commit that to git. If you remove something from the working tree, it still exists in git but we don’t care. We could save space, but that is an optimization problem, not a consistency problem.

KN: I thought about privacy. If you post something sensitive, then it will always continue to exist in the sync git.

[…]

KN: Do you know other federation test applications, and how to find out how AP works?

LD: I don’t know from the top of my head. There are some well-known ones… Mastodon, Peertube, um. Yeah I look at all the implementations. I found 3 or 4 that use Go-Fed. I was mostly interested in that. They are good examples to see how Go-Fed works. Altogether I found about 10 codebases I could get inspiration from. The one I was most interested in initially was Bookwyrm for booksharing federation. It is not free software, but with a special license that says: “If you don’t like us, then get away”. It is used for something different than chatting and different than Mastodon.

PS. My particular interest is about ActivityPub / Fediverse application development in general (for Solidground Matters), where:

  • It is not immediately clear to most developers how to fit federation support in the larger application design.
    • Your use of different open protocols / standards, here AP and Git, is a good example of practical design choices.
  • The fact that in order to learn more about ActivityPub, the best forward is still to delve in a whole bunch of codebases.
    • Specs and SocialHub forum, other articles, only bring one so far. Much knowledge is in fact code (literally hard-coded).
2 Likes
#7

The update will be repeated in French at https://meet.easter-eggs.com/fedeforges Thursday March 3rd, 2022 at 10:30am UTC+1. Anyone interested to join is welcome.

1 Like