C-toxcore: 새로운 휴대용 단순 표준 tox 저장 형식 만들기

또 다른 외부 의존성? 안 돼! 제발!
간단한 json 작성기/판독기를 작성하십시오. 클라이언트 간의 일부 메타데이터 전송에도 유용합니다.
그리고 까다로운 질문: 다른 고객이 이 인챈트를 지원하는 방법은 무엇입니까? 제가 알기로는 톡톡을 사용하는 클라이언트는 없습니다.

나는 이 형식이 클라이언트가 사용자 이름, 온라인 상태, 상태 메시지 및 친구 별칭 목록과 같은 항목을 저장할 수 있는 간단한 키-값 저장소를 제공해야 한다고 생각합니다(참조: #112). 그런 다음 클라이언트 상호 운용성을 보장하기 위해 일부 표준 키가 TCS 에 의해 정의됩니다.

https://github.com/TokTok/c-toxcore/issues/112#issuecomment -257151226을 입력하겠습니다.

@isotoxin 공격/버그 표면을 넓히고 있기 때문에 보안 통신을 담당하는 라이브러리에서 JSON 파서를 구현하려고 시도하는 것은 잘못된 것 같습니다. 예를 들어 JSON 구성을 원했다면 JSON을 처리하기 위한(그리고 _only_ JSON을 처리하기 위한) 잘 관리된 라이브러리로 이를 연기하는 것이 좋습니다. https://github.com/akheron/jansson/ 은 JSON 사례에 이상적인 후보처럼 보입니다. toxcore만큼 이식성이 뛰어나며 임베디드 플랫폼에도 적합합니다.

문서를 읽은 후 현재 형식이 끔찍하고 죽어야 한다는 데 동의합니다.

최소한의 클라이언트를 구현하는 데 필요한 항목을 최소화하려면 파일을 두 부분으로 분할해야 한다고 생각합니다.

• 기본 부분
• 선택 부품

기본 부분은 클라이언트 간에 친구를 전송하기 위한 최소한의 데이터(미정)를 간단한 형식(바이너리일 수도 있음)으로 포함하며 구문 분석을 위해 외부 라이브러리가 필요하지 않아야 합니다.

선택적 부분은 기본 부분에 추가되며 JSON(또는 무엇이든)으로 인코딩됩니다. 별칭, 지난번 온라인 등 모든 클라이언트에 필요한 몇 가지 키...

논의하다.

JSON 형식은 읽기 쉽고(인간의 경우) 크로스 플랫폼 자체로 안전하기 때문에 저는 JSON 형식의 아이디어를 좋아합니다. 실제로 하나의 추가 및 외부 라이브러리가 필요하지만 최소한 어떤 경우에는 클라이언트가 동일한 라이브러리를 사용하여 구성 처리의 일부(구성의 선택적 부분)를 처리할 수 있습니다. 또한 풍부한 콘텐츠를 포함할 수 있는 교차 플랫폼 구성 파일의 처리가 외부 라이브러리(JSON, msgpack, protobuf 등) 없이 수행되는 경우를 생각하는 데 어려움을 겪고 있습니다.

나는 tox 저장 형식이 두 부분을 포함할 수 있다는 갑작스러운6의 아이디어를 좋아합니다.
기본 부분 - 계정이 작동하는 데 필수적인 모든 절대적으로 필요한 데이터 부분을 포함합니다(toxcore에서 실제로 해석하는 부분만). 이 기본 부분은 최신 버전의 toxcore가 이전 버전에서 제거되지 않는 속성을 가질 수 있도록 버전도 지정할 수 있습니다. 문제없이.

선택적 부분 - 클라이언트 특정 정보 또는 작업을 수행하는 데 필요하지 않은 기타 정보를 포함할 수 있는

JSON 형식을 사용하면 저장 파일을 암호화하는 것이 간단합니다. Toxcore는 사용자가 지정한 암호로 일반적으로 사용되는 대칭 암호화 알고리즘을 사용하여 저장 파일을 암호화할 수 있습니다. 동시에 사용자가 자신의 저장 파일을 암호화하지 않으려는 경우 암호화가 필요하지 않으며 이 경우 toxcore는 암호화/복호화 단계를 건너뛸 수 있습니다.

두 부분 아이디어의 보안에 대해. 구성에 두 개의 개별 부분이 포함되어 있으면 기본 부분만 toxcore에서 실제로 해석되는 유일한 부분이 됩니다. 이 부분에서 toxcore는 내부 구조에 대한 모든 속성을 읽고 이 부분은 toxcore가 저장 파일을 저장할 때 다시 구성됩니다. 저장 파일의 선택적 부분에 대해 toxcore는 클라이언트에 대해서만 get 및 put 기능을 도입합니다. 이러한 기능은 클라이언트가 선택적 구성 부분을 가져오고 제공하는 데 사용됩니다. Toxcore는 클라이언트 측에서 JSON 라이브러리 관련 기능을 공개하거나 선택적 부분을 해석하려고 해서는 안 됩니다. 그러나 toxcore는 클라이언트가 잘못된 구성 섹션을 포함하려는 경우를 감지하기 위해 선택적 부분의 JSON 구문을 검증해야 합니다. 내가 옳다면 JSON의 유효하지 않은 섹션은 전체 JSON 구조를 무효화합니다. 이것은 toxcore에 의해 감지되어야 하며 잘못된 포함이 허용되어서는 안 됩니다. JSON의 구문 유효성 검사는 매우 간단하고 안전하며 라이브러리에서 이미 사용할 수 있어야 합니다.

기본 및 선택적 섹션이 있는 JSON 구성 파일의 장단점에 대해 생각해 보겠습니다.
장점

• 사람이 읽을 수 있는
• 동적, config는 다른 버전의 toxcore에서 이해할 수 없는 경우 새 속성을 건너뛰도록 버전을 지정할 수 있습니다.
• 단순(속성이 잘 정의된 구성의 최소한 기본 부분)
• 본질적으로 크로스 플랫폼
• 일반적으로 사용되는 형식, 다양한 언어에 사용할 수 있는 많은 라이브러리 및 구현.
• 텍스트 형식이 되려면 상대적으로 크기가 효율적입니다.
• toxcore는 필요한 경우 항상 간단한 버전의 저장 파일을 저장할 수 있습니다. 해당 저장 파일에는 선택적 부분 없이 구성의 기본 부분만 포함됩니다. (구성 팽창을 방지하고 버전에 독립적임)

단점

• 외부 라이브러리 필요
• 기본 및 선택적 분할로 인해 보안 문제 발생
• 바이너리 데이터에 비효율적(친구 아바타?)
• 클라이언트가 구성 저장 파일의 선택적 부분에 원하는 것을 자유롭게 포함할 수 있다면 엄청난 탄수화물 더미가 될 수 있습니다(장점 참조 -> 단순 버전 저장).
• toxcore는 구문 유효성을 검사해야 하지만 선택적 부분을 해석해서는 안 됩니다.

결국, 나는 tox 세이브 파일에 대한 JSON 형식의 아이디어를 좋아합니다. 그러나 구현은 신중하게 이루어져야 합니다! 더 많은 논의 부탁드립니다...

바이너리 데이터에 비효율적(친구 아바타?)

IIRC 아바타는 현재 *.tox 파일에 저장되어 있지 않고 구성 파일에 그렇게 많은 데이터를 저장하는 것은 정말 나쁜 생각이라고 생각합니다.

기본 및 선택적 분할로 인해 보안 문제 발생

왜요?

클라이언트가 구성 저장 파일의 선택적 부분에 원하는 것을 자유롭게 포함할 수 있다면 엄청난 탄수화물 더미가 될 수 있습니다(장점 참조 -> 단순 버전 저장).

예, 그것은 큰 문제로 커질 수 있습니다.

toxcore는 구문 유효성을 검사해야 하지만 선택적 부분을 해석해서는 안 됩니다.

또한 가능한 솔루션은 클라이언트가 선택에 따라 라이브러리로 JSON 구문 분석을 처리하도록 하고 적절한 구성 구조/함수로 toxcore를 초기화하는 것입니다. 그러나 출력 파일이 호환된다는 보장이 없기 때문에 이것이 좋은 방법인지 확신할 수 없습니다.

또 다른 아이디어는 "Tox 저장 파일"의 개념을 폐기하고 "Tox 내보내기 파일"을 제공하는 것입니다. 클라이언트가 시작할 때마다 저장 파일에서 모든 것을 저장/로드하는 대신 클라이언트는 자체 데이터베이스/저장 파일에서 toxcore 작업에 필요한 데이터를 로드하고 다른 사용자와 교환하기 위해 지정된 형식으로 데이터를 가져오거나 내보내는 방법만 제공합니다. 클라이언트.
장점

• 더 적은 구성 파일
• 파서 라이브러리에 대한 하드 종속성 없음

단점

• 모든 클라이언트가 가져오기/내보내기를 구현한다는 보장은 없습니다.

전반적으로 내용을 저장하는 방법 을 다루기 전에 먼저 이 파일에 무엇 을 저장할지 결정해야 합니다.

@master-passeli

JSON 형식을 사용하면 저장 파일을 암호화하는 것이 간단합니다.

암호화/복호화는 데이터 형식에 관계없이 간단합니다.

@sudden6

또한 가능한 솔루션은 클라이언트가 선택에 따라 라이브러리로 JSON 구문 분석을 처리하도록 하고 적절한 구성 구조/함수로 toxcore를 초기화하는 것입니다.

에, 아니, 해결책 이 아니라 잘못된 방식으로 일을 하고 있습니다.

나는 아바타를 tox 세이브 파일에 저장하는 것이 좋지 않을 수 있다는 데 동의하지만 아바타는 단지 예일 뿐입니다. 지금은 세이브 파일에 저장하고 싶은 바이너리 데이터가 생각나지 않지만 미래에는 가질 수 있습니다. 미래는 조금 예측하기 어렵습니다. :)

기본 및 선택 부분은 선택 부분이 클라이언트가 자유롭게 추가할 수 있는 경우 몇 가지 보안 문제가 있습니다. 이렇게 하면 버그가 있는 클라이언트가 잘 제작되거나 버그가 있는 데이터를 제공하여 tox core를 위험에 빠뜨릴 수 있는 몇 가지 방법이 열립니다. 나는 클라이언트가 추가한 부분이 toxcore에 의해 해석되지 않고 toxcore가 클라이언트가 포함하려는 부분을 구문적으로 검증함으로써 이러한 가능성을 최소화할 수 있다고 믿습니다.

@sudden6

내 말은 클라이언트가 toxcore에 의해 파일에 저장되고 로드되는 구성 부분에 대해 어떤 구문 분석 방법이든 사용할 수 있다는 것을 의미합니다. 예를 들어 Qt에는 자체 JSON 파서가 이미 있다고 생각하기 때문에 qTox에는 외부 JSON 파서가 필요하지 않습니다. 또한 클라이언트가 다른 언어로 작성된 경우 기본 JSON 파서를 소유할 수 있으며 C 파서 라이브러리는 상황을 더 복잡하게 만듭니다.

클라이언트가 자신의 내보내기 파일을 구현하는 아이디어가 마음에 들지 않습니다. 그런 식으로 많은 수의 호환되지 않는 내보내기 파일과 엄청난 혼란이 발생하지 않을까 걱정됩니다. 이것은 toxcore의 책임이자 기능이어야 합니다.

이러한 종류의 기본 및 선택적 부분 분리가 어떤 문제에서도 너무 위험한 경우 JSON 형식에 대해 여전히 +1을 제공합니다. 너무 많은 b *t XML 구성 또는 바이너리 * 더미를 보았습니다.