03:21:51 <m-relay> <j​effro256:monero.social> Is there any character limit for DNS records or openalias we could run into?
03:22:12 <m-relay> <j​effro256:monero.social> Just asking since new Jamtis addresses will likely be 244 characters long
05:29:17 <m-relay> <a​js_:matrix.org> jeffro256:  TXT record limited to 255 characters per string
07:59:52 <m-relay> <j​effro256:monero.social> TXT records don't have to actually contain human-readable data right? Is it an option to store addresses as raw bytes or that frowned upon in openalias?
08:00:37 <m-relay> <j​effro256:monero.social> Then Jamtis address as raw bytes is only 153 bytes
08:06:13 <m-relay> <j​effro256:monero.social> Also, can the key-value pairs appear in a different TXT record?
08:19:20 <m-relay> <a​js_:matrix.org> Has there been any work done on MoneroDNS?
08:21:11 <m-relay> <a​js_:matrix.org> IIRC, a few years ago there was talk about collaborating with Jeremy, dev from Namecoin
08:24:03 <m-relay> <j​effro256:monero.social> Sorry, I'm being loose with my terminology. Rather, does the OpenAlias spec care if the OpenAlias message with key/value pairs is spread across multiple strings within a TXT record with arbitrary breaks?
08:24:42 <m-relay> <j​effro256:monero.social> I've never heard of MoneroDNS
08:29:23 <m-relay> <a​js_:matrix.org> It was on the Monero roadmap of development back in 2016
08:30:17 <m-relay> <a​js_:matrix.org> Decentralized dns similar Namecoin’s .bit
08:32:33 <m-relay> <a​js_:matrix.org> https://web.archive.org/web/20170103072827/https://getmonero.org/design-goals/
13:47:49 <m-relay> <a​js_:matrix.org> MoneroKon 2024 Submission Deadline - 2 weeks™ - Submit a proposal for talk/workshop before 15th March - https://apply.monerokon.org
14:32:05 <dukenukem> C is now illegal. Byenance delists us. We're all doomed! https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
14:32:38 <moneromoooo> ffs, keep to #monero with the non dev stuff.
17:44:19 <m-relay> <v​tnerd:monero.social> jeffro256: I brought up the TXT limits immediately in the OA2 chatroom, and was informed that it's possible to concatenate the records
17:44:35 <m-relay> <v​tnerd:monero.social> The limit per record is 255.
17:46:18 <m-relay> <v​tnerd:monero.social> And I think TXT records can contain anything, but as noted in the chatroom if we go for a more compact format, it requires a tool to be run to generate the record, whereas it can be done by hand right now
17:46:59 <m-relay> <v​tnerd:monero.social> Although if we are spanning multiple records, it may require a tool to do the split effectively anyway
17:47:21 <m-relay> <v​tnerd:monero.social> I suggest joint #openalias chatroom
17:47:28 <m-relay> <v​tnerd:monero.social> *joining
17:50:14 <m-relay> <j​effro256:monero.social> Done thanks
17:51:37 <m-relay> <j​effro256:monero.social> Yeah  if the records can be concatenated, then it should definitely remain human readable since AFAICT mot DNS tools have human usable ways to make long DNS strings from my short 15 mins of research
18:57:43 <m-relay> <d​etherminal:matrix.org> bullish for cuprate
20:34:29 <m-relay> <s​omeoneelse495495:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/vvGyvblPEMBfnRSVNBVnINRh
20:34:52 <m-relay> <s​omeoneelse495495:matrix.org> why is the `fees` field in `get_fee_estimate` core rpc response not consistent
20:35:31 <m-relay> <s​omeoneelse495495:matrix.org> dont mind the change of ports, same behavior with or without restricted rpc
20:39:11 <UkoeHB> It's estimated from the current chain state, which changes.
20:39:56 <m-relay> <s​omeoneelse495495:matrix.org> So while it's changing it just disappear
20:40:09 <m-relay> <s​omeoneelse495495:matrix.org> So while it's changing it just disappear ?
20:55:58 <m-relay> <s​omeoneelse495495:matrix.org> Nevermind I realize I got the two possible rpc response, the one if `version >= HF_VERSION_2021_SCALING` and the else one (core_rpc_server.cpp). I still don't understand why tho since `get_current_hard_fork_version()` is `const`
21:58:15 <moneromoooo> Are you sure your daemon was not syncing old blocks when you got the < HF_VERSION_2021_SCALING version ?
22:17:58 <m-relay> <s​omeoneelse495495:matrix.org> I was indeed syncing... I thought it immediatly goes and check to the bootstrap daemon
22:23:42 <moneromoooo> It seems it does, from reading the source.
22:26:15 <m-relay> <s​omeoneelse495495:matrix.org> then it's weird. I shouldn't get the the pre 2021 response format