<html><head></head><body>   <div dir="auto">Worth noting that CrossWire is not the only server hosting SWORD modules!</div><div dir="auto"><br></div><div dir="auto">Refer to the relevant wiki page. </div><div dir="auto"><br></div><div dir="auto">David</div><div><br></div>  <div><br></div><div><br></div>On Sat, Jul 13, 2024 at 09:11, Peter von Kaehne <<a class="" href="mailto:On Sat, Jul 13, 2024 at 09:11, Peter von Kaehne <<a href=">refdoc@gmx.net</a>> wrote:<blockquote type="cite" class="protonmail_quote">  <div dir="ltr"><div>

    </div><div><div dir="ltr">You can ask for parts via the study application . I do not think anyone has yet decided to build an app around that. But I see no reason why not. It probably needs dusting off and some further work to make more universally useful, but it is uo and running and always available. </div>

    <div id="ms-outlook-mobile-signature"><div><br></div>Sent from <a href="https://aka.ms/o0ukef">Outlook for iOS</a></div>

<div> </div><hr tabindex="-1" style="display:inline-block;width:98%"><div dir="ltr" id="divRplyFwdMsg"><font face="Calibri, sans-serif"><b>From:</b> sword-devel <sword-devel-bounces@crosswire.org> on behalf of Aaron Rainbolt <arraybolt3@gmail.com><br><b>Sent:</b> Saturday, July 13, 2024 5:40 AM<br><b>To:</b> SWORD Developers' Collaboration Forum <sword-devel@crosswire.org><br><b>Subject:</b> [sword-devel] Creating a "SWORD-over-network" protocol for remote SWORD repo access?<div> </div></font></div>As it stands, SWORD users face some disadvantages when accessing SWORD

<br>resources - they have to be downloaded in their entirety, installed

<br>onto the end user's system, and then stay there for as long as the

<br>user wishes to access them. While it is possible and even easy to copy

<br>modules from one system to another in theory, the system that views

the modules must still *have* the modules in order to view them.

<br>

<br>Since SWORD already is basically a universal Bible-related data access

<br>system, it seems to me like it could be useful to take the concept one

<br>step further - allowing access to SWORD modules over the network,

<br>where a viewing device must only request the part of a module it wants

to view, and simply discards it when it's done with it.

<br>

<br>Some advantages of this over what SWORD already does:

<br>

<br>* The device used for viewing no longer has to be the device used for

<br>storing the modules. Individuals can stand up a "SWORD server" and

<br>then access the modules from any network-capable SWORD client on any

device.

<br>* The device used for module storage can be located on the Internet,

<br>allowing individuals to access a potentially large library of modules

without installation.

<br>* Assuming a properly secured, encrypted connection can be established

<br>and the server is not obvious as a SWORD server, individuals in

<br>persecuted countries could potentially access SWORD modules over the

<br>Internet, allowing them to access the Bible without leaving a trace on

their devices.

<br>* Organizations with permission to redistribute copyrighted texts

<br>could provide those texts via a SWORD server, allowing them to be

<br>accessed by network-capable SWORD clients (i.e., this could

<br>potentially allow people to legally access texts such as the ESV and

<br>NIV in their favorite SWORD client rather than being forced to resort

<br>to clunky websites, proprietary software, or piracy). Server-side,

<br>open-source DRM measures could be enforced to make downloading entire

<br>modules for offline use more difficult, providing some level of

peace-of-mind to copyright owners.

<br>

<br>Advantages this would have over existing "access the Bible online" solutions:

<br>

<br>* It would provide a standardized interface for accessing the Bible

<br>and Bible-related resources over the Internet, rather than every

<br>project coming up with its own storage conventions and network

protocols.

<br>* People could theoretically use almost any SWORD client to access the

<br>modules, allowing access to the Bible using a native desktop or mobile

<br>application, rather than having to resort to a web browser, clunky

<br>"cross-platform" (read: doesn't work quite right anywhere) app, or a

tracker-laden mess like YouVersion.

<br>* Since the SWORD server itself would essentially be a SWORD client

<br>that provided access to its modules over the network, one SWORD server

<br>could daisy-chain to another one, thus acting as a proxy. This way

<br>small, non-suspicious websites could provide access to major SWORD

<br>servers via a proxy, making it easier to help individuals in

persecuted situations to access the Bible.

<br>* Given the above proxying mechanism, blocking access to SWORD servers

<br>could become very difficult, for much the same reasons why blocking

<br>access to Matrix chat is very difficult. (In a world with unlimited

<br>time and development resources, a full federation system could be

<br>implemented so that anyone could access any module that anyone else

hosted... but that's almost without question overkill and impractical.

<br>Just proxying would be cheap to implement and powerful in use.)

<br>* Anyone could self-host a SWORD server and provide themselves, their

<br>family, their community, or even the world easier access to the Bible

and Bible-related resources.

<br>* Advanced features like fast Lucene search could be provided

<br>server-side, giving a much faster search experience than almost any

modern Web-based Bible application I've used.

<br>* If used alongside a feature like BibleSync, it could be a powerful

<br>tool for churches and Bible studies to use. People could simply

<br>connect to the church's SWORD server and enable BibleSync, then be

<br>able to follow along perfectly with everyone else, with access to the

<br>same resources that their pastor, study leader, etc. is actively

<br>using. No prep work needed (beyond having the proper app installed and

knowing how to point it to the right server).

<br>

<br>In the event this idea is actually worth pursuing, it seems to me like

there would be four things needed to make it a reality.

<br>

<br>* A SWORD network protocol specification. This would probably be the

<br>hardest thing to get right since it has to be gotten right the first

<br>time and then only incrementally updated in the future in a

backwards-compatible manner for best results.

<br>* An actual SWORD server implementation. Once the specification

exists, writing this should theoretically be easy.

<br>* Server access support in the SWORD library itself. This would enable

existing SWORD clients to adopt network support with little effort.

<br>* Adoption of the new feature by SWORD frontends. This of course is up

<br>to (and at the discretion of) each SWORD frontend developer, but if

<br>the SWORD library made accessing network resources act almost

<br>identically to accessing local resources, it would hopefully be easy

<br>to take advantage of the feature, and thus it would hopefully gain

traction.

<br>

<br>So there's my brain-dump of all the reasons I think this is worth

<br>doing and how I think it should be done :P Let me know what you think

<br>and if you have any advice or feedback. This whole thing popped into

<br>my head tonight and I just wanted to share it to see if it's worth

<br>pursuing, or if maybe something similar to this was tried already in

the past.

<br>

Thanks for reading my wall of text. God bless.

<br>_______________________________________________

<br>sword-devel mailing list: sword-devel@crosswire.org

<br>http://crosswire.org/mailman/listinfo/sword-devel

<br>Instructions to unsubscribe/change your settings at above page

<br></div></div>

<p>_______________________________________________<br>

sword-devel mailing list: sword-devel@crosswire.org<br>

http://crosswire.org/mailman/listinfo/sword-devel<br>

Instructions to unsubscribe/change your settings at above page<br>

</p></blockquote></body></html>