68 Matching Annotations
  1. Sep 2024
    1. it feels we’re creeping ever closer to that goal of providing the missing communication layer for the open Web. The European Union’s Digital Markets Act (DMA) is a huge step in that direction - regulation that mandates that if the large centralised messaging providers are to operate in the EU, they must interoperate. We’ve been busy working away to make this a reality, including participating in the IETF for the first time as part of the MIMI working group - demonstrating concretely how (for instance) Android Messages could natively speak Matrix in order to interoperate with other services, while preserving end-to-end encryption.

      Matrix seeing DMA as supportive towards their goal of open web's communication layer. Actively demo'ng Android interoperability while preserving E2EE, and participating in IETF / MIMI ( https://datatracker.ietf.org/group/mimi/about/ )

  2. Oct 2023
    1. UUID Version 7 (UUIDv7) is a time-ordered UUID which encodes a Unix timestamp with millisecond precision in the most significant 48 bits. As with all UUID formats, 6 bits are used to indicate the UUID version and variant. The remaining 74 bits are randomly generated. As UUIDv7 is time-ordered, values generated are practically sequential and therefore eliminates the index locality problem.


      0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unix_ts_ms | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unix_ts_ms | ver | rand_a | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |var| rand_b | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | rand_b | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  3. Sep 2023
  4. Jul 2023
  5. Jun 2023
  6. May 2023
    1. Proposal for internet wall . By Pradeep kumar Xplorer ex sun .com engineer currently victim of cybercrime using dhyanayoga.info california resident unable to return there and his mother murdered. If you like this proposal or design please email pradeepan88@hotmail.com and request some financial aid to expand the design and have the project rolling. I propose the internet wall . Wall is old unix command line utility where a user can message all users logged in with some wall message. Like the system administrator in the evening giving half an hour more time to finish work and log off, or informing of some meeting to discuss some projects.The internet wall is where you see the internet as a giant computer. Once you are online you are one user of the internet which can have several million to billion users online at the same time. The internet wall is a suite of applications cross platform cross domain that would be in your desktop or smart fone screen that you can invoke and wall everyone online or some subset of those who are online. I propose a website internetwall .com or or any other domain extensions

      😂🤣😭

      This draft is a rogue submission with author impersonation, isn't it ? 🤔

  7. Apr 2023
    1. If you'd like to make your own: Go to https://chat.openai.com/chat "Give me another title and abstract for a funny April 1 RFC about AI" Ask it to shorten the abstract if it's too long Ask it to write the introduction "Now write a terminology section. Make sure to include the RFC 8174 boilerplate." "Now write a section describing how the protocol works. Be detailed, and make sure to refer to some RFCs." "Now write a Security Considerations section and an IANA considerations section"
  8. Mar 2023
  9. Feb 2023
  10. Jan 2023
    1. We need to read the Signature header, split it into its parts (keyId, headers and signature), fetch the public key linked from keyId, create a comparison string from the plaintext headers we got in the same order as was given in the signature header, and then verify that string using the public key and the original signature.

      ```ruby require 'json' require 'http'

      post '/inbox' do signature_header = request.headers['Signature'].split(',').map do |pair| pair.split('=').map do |value| value.gsub(/\A"/, '').gsub(/"\z/, '') # "foo" -> foo end end.to_h

      key_id = signature_header['keyId'] headers = signature_header['headers'] signature = Base64.decode64(signature_header['signature'])

      actor = JSON.parse(HTTP.get(key_id).to_s) key = OpenSSL::PKey::RSA.new(actor['publicKey']['publicKeyPem'])

      comparison_string = headers.split(' ').map do |signed_header_name| if signed_header_name == '(request-target)' '(request-target): post /inbox' else "#{signed_header_name}: #{request.headers[signed_header_name.capitalize]}" end end

      if key.verify(OpenSSL::Digest::SHA256.new, signature, comparison_string) request.body.rewind INBOX << request.body.read [200, 'OK'] else [401, 'Request signature could not be verified'] end end ```

  11. Dec 2022
  12. Nov 2022
  13. Sep 2022
  14. Aug 2022
  15. Jul 2022
  16. Jun 2022
  17. Apr 2022
  18. Mar 2022
  19. Dec 2020
    1. Q_plain

      Is the entropy from Q_plain really needed? A reason for it would be that the client provides randomness with the nonce contained in Q_plain, in the sense of a contributive key exchange. However, the client already contributes the HPKE ephemeral key.

      If the Extract step should stay, I suggest changing the order of Q_plain and odoh_secret. The value odoh_secret is of fixed size and uniformly random, and thus fits better as salt to HKDF-Extract. If the first value is longer than a hash function block size, HMAC will do an additional hashing step: This seems easily possible for Q_plain.

  20. Nov 2019
  21. Oct 2018
  22. Mar 2018