Conversation

Notices

1. jaf (jeff@misinformation.wikileaks2.org)'s status on Monday, 03-Jul-2023 23:08:20 JST jaf
   FART 0000: your opinion has been noted.
   
   #FART (fediverse administration recommended technique) number 0000 describes opinions and findings of admins on fedi wrt enabling the interoperatation between networks for the syndication of user data.
   
   i want to start a discussion on what different admins have found wrt running infra on fedi, what their use case is, what challenges they faced and what features their users ask for.
   
   idc if people archive this i just want to ask what people have learned so far and see if i get a compilation of technical opinions that i can use later. if you find such useful archive it. just asking others on it.
   • jaf (jeff@misinformation.wikileaks2.org)'s status on Tuesday, 04-Jul-2023 21:32:29 JST jaf

     in reply to

     • LisPi
     @lispi314 kind of but not really. it is totally undefined behavior
   • LisPi (lispi314@mastodon.top)'s status on Tuesday, 04-Jul-2023 21:32:30 JST LisPi

     in reply to

     @jeff Wait, so currently failures don't result in requeuing for later retries and dropping after persistent failure (like email does after a while)?

     Machismo repeated this.
   • jaf (jeff@misinformation.wikileaks2.org)'s status on Tuesday, 04-Jul-2023 21:32:31 JST jaf

     in reply to
     #FART 0001: is your federation queue congestion control worse than usenet?
     
     the answer is likely, yes. right now federation job timeouts seem to be too high and easy to backlog federation queues. fail fast fail often is a good default we do not have right now, tbh we need a more rigorously defined method of federation queue congestion control where drop is tolerated and higher latency federation does not occur as bad.
     
     tcp has 50 years of data behind such and i think we should start figuring out how to bake into the protocol hints about congestion windows. this was solved in the freaking 1980s why cant we learn from that?