@JM
Educator, Dev from busan
Relays (3)
- wss://testrelay.era21.space – read & write
- wss://nos.lol – read & write
- wss://relay.damus.io – read & write
Recent Notes
ndk vs nostr-tools
ndk 가 이벤트처리 방식이 await on publish 방식이여서
전송한 event 가 OK 날 때 까지 오래걸림.
nostr tools는 Fire&forget 방식이라 OK 신경안씀
병...
엌ㅋㅋㅋㅋㅋ 클플 터널 RTT 70ms 나올텐데 250ms 달성
1
ndk vs nostr-tools
ndk 가 이벤트처리 방식이 await on publish 방식이여서
전송한 event 가 OK 날 때 까지 오래걸림.
nostr tools는 Fire&forget 방식이라 OK 신경안씀
병...
요거 다음으로 nostr-rs-relay (러스트 릴레이)
가 emphemeral event(20000~29999) 도 영구저장 이벤트랑 같은 큐를 공유하는데, 임시 이벤트용 큐를 분리하면 처리 방식에서도 레이턴시에 상당한 이득을 얻을듯함.
가 emphemeral event(20000~29999) 도 영구저장 이벤트랑 같은 큐를 공유하는데, 임시 이벤트용 큐를 분리하면 처리 방식에서도 레이턴시에 상당한 이득을 얻을듯함.
미들웨어로 선회.
노스터 라이브러리리 병목 + 릴레이 emphemeral event 처리 병목이 의심된다.
로컬 환경에서도 800ms 대 레이턴시가 나옴.. (http 는 0.15us)
...
ndk vs nostr-tools
ndk 가 이벤트처리 방식이 await on publish 방식이여서
전송한 event 가 OK 날 때 까지 오래걸림.
nostr tools는 Fire&forget 방식이라 OK 신경안씀
병목이 라이브러리에서 오는거같은데
로컬 릴레이 기준 벌써 36.7ms 달성.. ㄷㄷ
클라이언트<->릴레이<-> 앱서버 간에 현실적으로 300ms 안팎으로 될듯
세션키(대칭키) 방식으로 전환하면 계산 비용줄이고 레이턴시도 트래픽도 줄일 수 있을듯
ndk 가 이벤트처리 방식이 await on publish 방식이여서
전송한 event 가 OK 날 때 까지 오래걸림.
nostr tools는 Fire&forget 방식이라 OK 신경안씀
병목이 라이브러리에서 오는거같은데
로컬 릴레이 기준 벌써 36.7ms 달성.. ㄷㄷ
클라이언트<->릴레이<-> 앱서버 간에 현실적으로 300ms 안팎으로 될듯
세션키(대칭키) 방식으로 전환하면 계산 비용줄이고 레이턴시도 트래픽도 줄일 수 있을듯
2
미들웨어로 선회.
노스터 라이브러리리 병목 + 릴레이 emphemeral event 처리 병목이 의심된다.
로컬 환경에서도 800ms 대 레이턴시가 나옴.. (http 는 0.15us)
병목 줄이면 200ms 대로 가능할거같은데..
노스터 라이브러리리 병목 + 릴레이 emphemeral event 처리 병목이 의심된다.
로컬 환경에서도 800ms 대 레이턴시가 나옴.. (http 는 0.15us)
병목 줄이면 200ms 대로 가능할거같은데..
4
DNS 레코드로 gw ip가 들어가기 때문에
GW에 별도 등록없이 ( 도메인 화이트리스트도 가능)
프록시 등록이 가능해질것같아요.
모든 HTTP 연결과 응답이 GW와 노스터를 거치기 때문에 트래픽 부담이 늘어남.
또한 GW는 모든 http 트래픽을 볼 수 있기 때문에
현재 https or ee2e 방법이 필요함
완화 방법으로는 클라이언트가 우선 http로 연결한 후에
JS로 nostr sdk를 다운받고
로컬노스터 프록시를 만들어 모든 트래픽을 nostr 기반으로 전송하는 nostr 네이티브 전환이 필요함
또한 GW는 모든 http 트래픽을 볼 수 있기 때문에
현재 https or ee2e 방법이 필요함
완화 방법으로는 클라이언트가 우선 http로 연결한 후에
JS로 nostr sdk를 다운받고
로컬노스터 프록시를 만들어 모든 트래픽을 nostr 기반으로 전송하는 nostr 네이티브 전환이 필요함
노스터를 터널링 프록시로 사용한다면 얼마나 쩔까요
지금 노스터 터널링 프로토콜을 만들어보고 있어요.
앱 서버는
1. 자신의 dns 레코드에 txt로 - p...
DNS 레코드로 gw ip가 들어가기 때문에
GW에 별도 등록없이 ( 도메인 화이트리스트도 가능)
프록시 등록이 가능해질것같아요.
GW에 별도 등록없이 ( 도메인 화이트리스트도 가능)
프록시 등록이 가능해질것같아요.
1
노스터를 터널링 프록시로 사용한다면 얼마나 쩔까요
지금 노스터 터널링 프로토콜을 만들어보고 있어요.
앱 서버는
1. 자신의 dns 레코드에 txt로 - pubkey + relay + 게이트웨이 서버 ip 추가
크ㄹ라이언트는
1. 도메인으로 http 요청
2. 게이트웨이는 도메인 보고 앱서버 노스터 정보 휙득
3. 게이트웨이가 노스터로 요청 전송
4. App 서버는 res를 릴레이로 전송
5. GW는 res 를 릴레이에서 받음
6. 클라이언트에게 반환
어떤가요?
지금 노스터 터널링 프로토콜을 만들어보고 있어요.
앱 서버는
1. 자신의 dns 레코드에 txt로 - pubkey + relay + 게이트웨이 서버 ip 추가
크ㄹ라이언트는
1. 도메인으로 http 요청
2. 게이트웨이는 도메인 보고 앱서버 노스터 정보 휙득
3. 게이트웨이가 노스터로 요청 전송
4. App 서버는 res를 릴레이로 전송
5. GW는 res 를 릴레이에서 받음
6. 클라이언트에게 반환
어떤가요?
2
아 비트코인 사고싶다
GM
1❤️1
It uses spark & centralized(they said decent) exchange to sell volatility to maintain stable balance
Yeah UX is better, but centralized.
Does exchange is replaceable to another service provider?
If no, i rather use stable channels.
Yeah UX is better, but centralized.
Does exchange is replaceable to another service provider?
If no, i rather use stable channels.
