Hacker News 의견

• 연속된 ID를 사용하는 회사로부터 비즈니스 인사이트를 얻을 수 있는 가능성

  • 예를 들어, 회원가입 시 부여받은 ID로 회사의 성장률 추정 가능
  • 애플리케이션 내 모든 리소스 유형에 적용 가능
  • URL 바에 있는 '쓰레기 값'이 요즘 시대에 얼마나 중요한지 의문
  • 대부분의 브라우저가 URL 대부분을 숨기기 때문에 UUID v7의 널리 퍼진 사용을 기다리며, uulids 사용
  • 내장된 시간 구성 요소가 때때로 유용함 (예: 객체 병합 규칙)

• 일회용 패스코드 언급에 대한 의문

  • 패스코드는 예측 불가능해야 하지만, 반드시 고유할 필요는 없음
  • 적절한 랜덤 소스를 제공하면 작동하지만, '쓰레기 값으로 채워진' 특징은 실제보다 복잡해 보임
  • 4~8개의 랜덤 숫자가 잘 작동하며 보안 수준을 명확히 제공
  • 숫자는 대소문자 구분이 있는 라틴 문자보다 이해하기 쉬움, 특히 다른 문자 체계를 사용하는 언어 사용자에게

• 128비트 정수나 바이트 배열을 포맷할 수 없는 것에 대한 실망

  • UUID 포맷팅이 가능하게 해줄 것
  • 공개적인 정수 ID 사용에 대한 선호도 낮음
  • 오름차순 ID로 중요한 정보 유출 위험 존재
  • URL, QR 코드 등을 위해 UUID를 Base64URL로 포맷팅하여 짧게 만드는 것을 선호

• Ruby 애플리케이션에서는 높은 기수로 변환하는 방법 사용

  • Sqid는 Ruby 라이브러리를 제공하고 훨씬 높은 기수 설정을 허용, 대문자 문자 및 이모지 포함
  • 공간 절약이 큰 차이를 만들기 전에 훨씬 더 큰 숫자가 필요
  • 새로운 의존성을 추가할 가치가 있는지 알기 어려움

• 욕설 필터링이 설계상 책임이 될 수 있음

  • 인코딩을 보존하기 위해 금지된 단어 목록을 불변으로 유지해야 함
  • 그렇지 않으면 이전 sqids가 잘못된 것으로 디코드될 수 있음

• nanoid 사용과 안전한 문자 사전의 사용을 선호

  • '나쁜' 단어를 찾기 위해 하드코딩된 구현 대신 유사한 사전 접근 방식 사용을 제안
  • 성능 테스트 스위트에 대한 관심 표명
  • 대부분의 언어에서 UUID v4 생성이 최적화되어 있어 사용자 정의 솔루션이 실제로 더 나은지 의문

• 무작위로 생성된 문자열의 사용에 대한 논의

  • ID, 비밀번호 복구 토큰 등에 사용
  • 수백만 개 생성되었으며 매일 수십만 명이 이를 확인
  • 무작위 컨텐츠 ID에 대한 불만 사례 없음
  • 현대 사회가 누군가를 모욕하는 것을 너무 두려워하여, 욕설 필터가 데이터베이스 ID와 비밀번호 복구 토큰에까지 확장됨
  • 최소 길이를 8로 설정하면 전체 ID로서 완전한 단어 욕설이 나타날 가능성이 낮음

• "Get Started" 섹션에서 40개 언어에 대한 링크 제공에 대한 혼란

  • 40개 중 15개 언어만 시작할 수 있으며, 나머지 25개는 관심을 나타내기 위해 사람들이 저장소를 시작하도록 요청하는 골격 저장소임

• 블록리스트를 조정하거나 발전시키는 방법에 대한 질문

  • ID가 블랙리스트에 있으면 단순히 증가
  • ID는 블랙리스트 내용에 고정되어 있으며, 이를 조정하면 이전에 생성된 ID의 특정 세그먼트가 무효화됨

• 이 스레드에서 많은 사람들이 ID/숫자에서 인사이트를 숨기는 좋은 방법이라고 언급

  • 생성된 값이 쉽게 디코드될 수 있으므로, 몇 개의 숫자를 디코드하여 인사이트를 얻을 수 있지 않을까 하는 의문 제기