--- Log opened vie abr 15 00:10:22 2022 00:10 -!- Irssi: #friendica: Total of 9 nicks [0 ops, 0 halfops, 0 voices, 9 normal] 00:11 -!- Irssi: Join to #friendica was synced in 64 secs 03:44 < fikabot> πŸ’¬ bkil: gitea as hosted by codeberg.org is an option. But... even gitea development happens on github, it's not that easy to move a project once it has settled somewhere and attracted contributors 03:45 < tyil> if only we had some decentralized tool for sharing our codebases and patches 04:14 < fikabot> πŸ’¬ I work only on https://git.friendi.ca/lubuwest and https://codeberg.org/lubuwest. I really like gitea. 05:00 < fikabot> πŸ’¬ erkie: If there existed a bot through which you could participate indirectly in such discussions, would you? 05:01 < fikabot> πŸ’¬ As in https://blog.codeberg.org/first-codeberg-hackathon-in-april-2022.html https://codeberg.org/Codeberg/Community/issues/607 09:49 < fikabot> πŸ’¬ bkil: My forum presence/activity varies a lot, but I would participate. 09:49 < fikabot> πŸ’¬ 09:49 < fikabot> πŸ’¬ I'm not sure I fully get the "client-side bot" idea, wouldn't that need a ProprietaryForge account anyway? In general the proxy/bot sounds like a great idea. 09:50 < fikabot> πŸ’¬ Also, I'm very interested in how the forge federation evolves. It's a pity the underlying git is distributed, but then issues et.c makes it all centralized. 09:51 < tyil> issues used to be just threads on a mailing list, which in turn is decentralized by virtue of email being decentralized 09:52 < tyil> which I think was good enough, but it can easily be argued you need something "better" 10:25 < fikabot> πŸ’¬ tyil: Actually, mailing list archives and mailing list distribution itself has always been centralized. You seem to be mistaking it for NNPT and EchoMail. 10:25 < tyil> the archives, sure, but Im talking about the emails themselves 10:25 < fikabot> πŸ’¬ erkie: Client side participation is only something I threw in as an alternative with better scaling potential instead of or along with operating our own centralized bot. So you could have the option to participate either way. 10:27 < fikabot> πŸ’¬ tyil: No, it's not just the archives. You send your email in reply to a mail to the centralized mailing list server, the centralized server processes it, filters it (access control, spam, etc), transforms it (adds headers, signatures, etc) and then sends it out to each individual subscriber within its centralized database (that may also be storing PII indefinitely by design) 10:28 < fikabot> πŸ’¬ Note that large mailing list servers can have a hard time because their outband email volume is so large, it gets signalled by various systems and/or their messages going to spam. If you looked around, it's also a special tier within PaaS/IaaS if you want to operate such a node that sends out a lot of bulk mail by design. 10:28 < fikabot> πŸ’¬ I can't think of any way we could go _more_ centralized than this. 10:28 < tyil> github is more centralized than that ;) 10:28 < fikabot> πŸ’¬ If you are using a Friendica Forum, it is way may decentralized. 10:28 < tyil> its pretty easy to think of more centralized options 10:29 < fikabot> πŸ’¬ A Friendica Forum ensures that pairs of instances exchange messages in batches. Publish-subscribe is way more efficient than SMTP for this. 10:29 < tyil> I dont *need* a specific single ML server, you can easily have multiple Tos or CCs 10:29 < fikabot> πŸ’¬ Not sure what you are talking about. How can you host a mailing list on _multiple_ servers at once? 10:30 < fikabot> πŸ’¬ I'm happy I could help you this time as well, but as I see we are not getting anywhere. See you tomorrow. 10:30 < tyil> its pretty common to have more than one server in your MX listed, actually 10:59 < fikabot> πŸ’¬ Mailing lists are great, I often find email to be the only messaging form everybody uses. (Insert xkcd 1810 :-) 11:01 < tyil> yeah, email is incredibly common, and well supported 11:02 < tyil> that said, email has some drawbacks like encryption not really being a thing, and impersonation being ridiculously easy (though for both there are workarounds, neither of them make it any more user friendly) 11:02 < tyil> but it also has ridiculously good backwards compatibility :p 11:02 < tyil> and a very easy protocol if you want to automate some things 11:04 < fikabot> πŸ’¬ Having said that... For a list to scale beyond a handful members, the list of subscribers should be centralized. 11:05 < fikabot> πŸ’¬ Even with 10-20 members, getting everybody to use the same set of TO: or CC: is a nightmare. People tend to just reply-to-all of some random message, leaving newcomers out of the discussion and pulling in people who left a long time ago. 11:05 < fikabot> πŸ’¬ And then others reply to that email, perpetuating chaos :-( 11:05 < tyil> it could be made less centralized, but this would require having a very public list of members, which may not be desired 11:06 < tyil> even with this drawback, I think email is one of the better options to have 11:07 < tyil> I greatly enjoy using sourcehut since it is based around email, you dont need to register yet another account to send a patch 11:07 < tyil> all the tools you require are baked into git itself 11:11 < fikabot> πŸ’¬ Also, I think emails have other, important limitations. It's difficult to reference a specific previous message/comment; even if there are unique message id's, they're part headers and not part of the UI. 11:14 < fikabot> πŸ’¬ Emails also tend to carry a lot of cruft. Signatures/footers, replies with quoted context (inline, top, bottom). html parts that are out of sync with the pure text part. 11:18 < fikabot> πŸ’¬ So, I'm less enthusiastic about email as such for issues and discussions. Perhaps it would be possible to build a client that uses email as the transport medium, while making sure the payload is well structured - not some fluffy text from which clever parsing might extract something meaningful from. 11:19 < fikabot> πŸ’¬ But then, why use email for transport? Why not Matrix, XMPP, or some ActivityPub implementation instead? 11:19 < fikabot> πŸ’¬ /rant 11:32 < tyil> not matrix because it's not a great protocol, but AP might be a solid choice, yes 13:04 < fikabot> πŸ’¬ > <@bkil:grin.hu> Hank: What do you mean exactly? Are you not satisfied with the existing options that adjust automatic optimization, cleanup and caching? 13:04 < fikabot> πŸ’¬ 13:04 < fikabot> πŸ’¬ Well I'm a bit surprised at how large the DB has gotten for relatively limited usage account, yes 13:05 < fikabot> πŸ’¬ I still have a substantial amonut of data in the storage table that isn't contact photos, media, etc. 13:05 < fikabot> πŸ’¬ I can only imagine how large that would be if there was a trawler type thing to bring more content into the server 13:05 < fikabot> πŸ’¬ besides what I'm getting from the 130 connections I have and however many the other user has 17:34 < fikabot> πŸ’¬ Heck, I told someone about Friendica putting gigabytes of photos in a database table and they giggled. The conversation started off from why anyone would find 30MB of hosted database storage quota a grave limitation. 19:36 < fikabot> πŸ’¬ But don't forget, that she who sells the apples gets to come up with the proverbs! https://docs.oracle.com/database/121/ADLOB/adlob_fs.htm "Introducing the SQL database file system - Oracle DBFS" 20:09 < fikabot> πŸ’¬ Oh can’t wait to install that! /sarcasm 21:41 < fikabot> πŸ’¬ Akshully I'm going to run it on Solaris! 21:42 < fikabot> πŸ’¬ https://matrix.org/_matrix/media/v1/download/myportal.social/jOwzUxOehxgOaBXUtFUxchwf --- Log closed sΓ‘b abr 16 00:00:05 2022