Reminder: travel grant applications due by May 10, 2024
We're pleased to offer a number of Diversity Travel Grants to support early-career academics and PhD students from under-represented groups to attend the Applied Networking Research Workshop (ANRW'24) and IRTF meetings co-located with the #IETF 120 Meeting in Vancouver, Canada, in July 2024. https://www.irtf.org/travelgrants/
@julian I think the best way is to subscribe to the the mailing list and reply to state your interest to participate and in what way.
I am not sure about how-to-subscribe for this particular list, and I'm not subscribed myself. I created the socialhub topic to draw attention to fedi dev community there.
See that there's a 'reply' icon on the thread, which pops up an email form. Dunno if that works. #IETF Search finds zilch searching for #WebFinger weirdly enough.
I do appreciate how, when writing #IETF drafts using the markdown template and GitHub, every writing session starts with spending 30 minutes debugging Python and Ruby build issues – this always make me feel more productive
More straws on the #DNS camel: another #IETF draft to amend RFC 1035. :)
"4. Updates to RFC 1035
A DNS message with OPCODE = 0 (QUERY) MUST NOT include a QDCOUNT parameter whose value is greater than 1. It follows that the Question Section of a DNS message with OPCODE = 0 MUST NOT contain more than one question.
A DNS message with OPCODE = 0 (QUERY) and QDCOUNT > 1 MUST be treated as an incorrectly-formatted message. The value of the RCODE parameter in the response message MUST be set to 1 (FORMERR)."
domain names cost too much, literally the fakest economy in existence. Yhey just need to cover the funding of ICANN and the IETF which should be no more than 50 furrys (network engineers) and 10 old guys on a board (they work for free they like it).
Hot on the heels of a post I wrote 4 years ago, wouldn't it be useful to have a well-known URl for user avatar images? When I sign up to a web service, I don't want to faff around uploading an image to use as my avatar. I want that service to look at my […]
Going through some of my old photos. I found the photo where we discussed on May 18, 2004 in New-York (20 years ago), where should be developed the Atom feed format: #W3C or #IETF.
Next session of the #IETF e-impact group for decreasing "#environmental impact" of networking technologies is meeting up 15-16. February! It's online & open to all; we will talk about protocols & #sustainability, drafts & carbon-aware routing ... and all the topics that you might bring, such as #DeGrowth, #permacomputing, planetary #limits, #ClimateJustice...
Interesting proposal for a top-level domain (TLD) that you could use internally on your LAN that will never be available out on the public Internet. So you could give your servers names ending in “.internal” and those addresses would not conflict with public addresses.
It uses a relay (so similar to VPNs or Tor), and asymmetrical cryptography to encrypt the final request to the server (so no man in the middle, even when no HTTPS).
It has some limitations though, mainly that, if I understand correctly, the HTTP server needs to be aware of the protocol and implement it, and also, it's saying it can't relay cookies? (that would be a severe limitation, meaning no using it for a website where you're logged in). I'm unsure if they say cookies can't be used, or using cookies negates the benefits (one of their goal being to make subsequent requests not identifiable). Tor still seems like the best choice for #privacy , but it's nice to see the matter being worked on by the #IETF
Also worth noting that the authors are from Mozilla and Cloudflare.
If you use #GnuPG#GPG, and you would like to ensure interoperability with Thunderbird, you might consider to disable the use of #LibrePGP features, by using option --rfc4880 in your configuration (e.g. by adding a line with the word "rfc4880" to your gpg.conf file.)
At this time it is undecided whether future Thunderbird versions will support LibrePGP or the upcoming refresh of the #IETF#OpenPGP specification, or both, or none of them. Hopefully we'll eventually see a new universal standard.
I also wrote about my one disagreement with Russ where he advocates for writing drafts in XML, but I have become a strong advocate for using Markdown in most cases.
This is how I want our network to evolve in 2024. Some of the things listed here may have been implemented already by a small number of projects, but more work is required on standards and interoperability.
Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.
End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.
Connectivity. Improving connectivity means fighting indiscriminate instance-level blocks, expanding to overlay networks (Tor, I2P and others), maybe also developing standards for bridges. In many ways, these tasks are linked to data portability.
Moderation / spam resistance. Anything other than "list of instances I don't like" would be a huge improvement. Fediseer is an interesting development, but still leaves a lot to be desired. Additionally, standardization of reply controls is needed. FEP-5624 exists, but the mechanism described there has many flaws.
Scalability. How to publish to 1M followers from a single-user instance running on cheap hardware? FEP-8b32 should make various optimizations possible (inbox forwarding, efficient reposts, etc).
Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
Discovery. Content discovery on small instances: relays and related standards, decentralized search.
Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.
URL handlers. Again, competing standards: FediLinks, FEP-07d7 and several other proposals.
Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.
Synchronization of replies. Various approaches are being considered, but there's no clear winner.
Markets. So far there's only one server implementation capable of processing payments. FEP-0837 (a protocol for federated marketplace) was designed, but lacking adoption.
Forge federation. ForgeFed is being implemented in Forgejo, although the work is progressing very slowly.