Re: INN over IPFS?
mfidelman protocoltechnologiesgroup.com <[email protected]> Sun, 15 Dec 2024 14:42:26 +0000
| Newsgroups | gmane.network.inn |
|---|---|
| Message-ID | <SA1PR12MB7038BB30D1C5F04CD951F0D3B13A2@SA1PR12MB7038.namprd12.prod.outlook.com> |
--===============6558596628095849297== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_SA1PR12MB7038BB30D1C5F04CD951F0D3B13A2SA1PR12MB7038namp_" --_000_SA1PR12MB7038BB30D1C5F04CD951F0D3B13A2SA1PR12MB7038namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was specifically wondering about the experiment of backing newspools with= IPFS - I'm pretty sure I read about this a while back - and was wondering = if anybody had any more details. As a transport, that's a whole different matter. What we're talking about = there is a single replicated spool file per newsgroup. And working out a w= ay to post to it like a CRDT log file. That's a separate set of issues. B= ut it does raise the question: Is there a canonical URL format for https a= ccess to a news spool? Thanks, Miles ________________________________ From: inn-workers <[email protected]> on behalf of Martin B= urmester <[email protected]> Sent: Sunday, December 15, 2024 7:58 AM To: [email protected] <[email protected]> Subject: Re: INN over IPFS? Hi, Am 06.12.2024 um 10:39 schrieb Jason Evans: > On 12/4/24 2:00 AM, Grant Taylor wrote: >> As has been discussed (at length) on other lists, IPFS is meant for >> FILES. >> >> As such, just about anything and everything that has Protocol in it's >> name is not natively compatible with a file system as it's >> communications mechanism. >> >> You could probably store a traditional news spool on IPFS, but it >> would almost certainly be inherently single point of update to avoid >> issues with overview databases and article numbers, etc. >> >> But you probably could get traditional news clients that read from the >> raw news spool to read articles. I have no idea how the posting would >> go because that will almost certainly involve <something> Protocol >> <maybe something else>. > > I was thinking the same thing. I really like the idea of distributed > news articles but this would mean writing something from scratch. If you > were to go down this rabbit hole, I would suggest reading the main NNTP > RFCs to get a good understanding and then go from there. I think you > would definitely need to introduce a universal article identifier and I > don't know if the "message-id" could do that. What you can probably do is write out uucp batch files periodically and store them in ipfs, other systems could look regularly and import the batches via rnews. Wouldnt have to reinvent the wheel but start from send-uucp and adapt it. Its one way only though. Cheers, Martin -- inn-workers mailing list [email protected] https://lists.isc.org/mailman/listinfo/inn-workers --_000_SA1PR12MB7038BB30D1C5F04CD951F0D3B13A2SA1PR12MB7038namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> I was specifically wondering about the experiment of backing newspools with= IPFS - I'm pretty sure I read about this a while back - and was wondering = if anybody had any more details.</div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> As a transport, that's a whole different matter. What we're talking a= bout there is a single replicated spool file per newsgroup. And worki= ng out a way to post to it like a CRDT log file. That's a separate se= t of issues. But it does raise the question: Is there a canonical URL format for https access to a news spool?</div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> Thanks,</div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> Miles</div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: "Times New Roman&q= uot;, Times, serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" id=3D"Signature"> <div style=3D"direction: ltr; text-align: left; text-indent: 0px; margin: 0= px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, H= elvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <b><br> </b></div> <div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, = Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> <br> </div> </div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> inn-workers <inn-w= [email protected]> on behalf of Martin Burmester <martin@b= urmester.org><br> <b>Sent:</b> Sunday, December 15, 2024 7:58 AM<br> <b>To:</b> [email protected] <[email protected]><br> <b>Subject:</b> Re: INN over IPFS?</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">Hi,<br> <br> Am 06.12.2024 um 10:39 schrieb Jason Evans:<br> > On 12/4/24 2:00 AM, Grant Taylor wrote:<br> >> As has been discussed (at length) on other lists, IPFS is meant fo= r <br> >> FILES.<br> >><br> >> As such, just about anything and everything that has Protocol in i= t's <br> >> name is not natively compatible with a file system as it's <br> >> communications mechanism.<br> >><br> >> You could probably store a traditional news spool on IPFS, but it = <br> >> would almost certainly be inherently single point of update to avo= id <br> >> issues with overview databases and article numbers, etc.<br> >><br> >> But you probably could get traditional news clients that read from= the <br> >> raw news spool to read articles. I have no idea how the post= ing would <br> >> go because that will almost certainly involve <something> Pr= otocol <br> >> <maybe something else>.<br> > <br> > I was thinking the same thing. I really like the idea of distribu= ted <br> > news articles but this would mean writing something from scratch. If y= ou <br> > were to go down this rabbit hole, I would suggest reading the main NNT= P <br> > RFCs to get a good understanding and then go from there. I think you <= br> > would definitely need to introduce a universal article identifier and = I <br> > don't know if the "message-id" could do that.<br> <br> What you can probably do is write out uucp batch files periodically and <br= > store them in ipfs, other systems could look regularly and import the <br> batches via rnews. Wouldnt have to reinvent the wheel but start from <br> send-uucp and adapt it. Its one way only though.<br> <br> Cheers,<br> Martin<br> <br> -- <br> inn-workers mailing list<br> [email protected]<br> <a href=3D"https://lists.isc.org/mailman/listinfo/inn-workers">https://list= s.isc.org/mailman/listinfo/inn-workers</a><br> </div> </span></font></div> </body> </html> --_000_SA1PR12MB7038BB30D1C5F04CD951F0D3B13A2SA1PR12MB7038namp_-- --===============6558596628095849297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- inn-workers mailing list [email protected] https://lists.isc.org/mailman/listinfo/inn-workers --===============6558596628095849297==--