Enhancement: in-app discovery of open group servers and their groups

[ianmacd]

I recently submitted a patch (#2230) to add to Session a button that opens the Lokilocker site in the user's browser, allowing him to browse a manually maintained directory of open groups and select URLs for entry into Session.

The intention of the patch was more to highlight the need for better open group support more than it was an attempt to address the issue. Because clearly the best solution from a technical standpoint is to have open group discovery fully integrated in the software à la Telegram or a Usenet reader.

@KeeJef commented that "there is a larger discussion which needs to occur around open group discoverability before any new discoverability buttons/features are merged".

This GitHub issue is being opened as a publicly accessible venue for that discussion.

[antonyho]

An in-app discovery is definitely needed. What are the concerns from Oxen dev side?
I have following concerns.

• Should be use 3rd party directory list?
• What happens when there is downtime on this site?
• Who has the ownership to maintain the list in a 3rd party site?
• Is there any responsibility on the listed open groups to avoid scam, drugs dealing, child porn, or any other illegal topic/content? When it is listed by the app, this will be Oxen's matter. And then Oxen has to respect and to fulfill the T&C from Alphabet and Apple as well, if the app is hosted on Play Store and AppStore.

[slrslr]

I am wondering about this case: Session does not suggest any third party group, but offer users search in distributed table of all open groups and joining, would that be an app store policy violation when an app allows finding/joining/participating in a group named Drug market with bad posts?

https://developer.apple.com/app-store/review/guidelines/#legal
https://www.reddit.com/r/applestore/

https://play.google.com/about/developer-content-policy/ - https://play.google.com/about/developer-distribution-agreement.html
https://www.reddit.com/r/googleplay/

Problem? Link users to some major group list like https://lokilocker.com/Mods/Session-Groups/wiki/Session-Open-Groups or to a search engine which would return groups: https://duckduckgo.com/?q=Session+http%3A%2F%2F*public_key%3D* (does not work, just for example).

[KeeJef]

Primary issue is here

Is there any responsibility on the listed open groups to avoid scam, drugs dealing, child porn, or any other illegal topic/content? When it is listed by the app, this will be Oxen's matter. And then Oxen has to respect and to fulfill the T&C from Alphabet and Apple as well, if the app is hosted on Play Store and AppStore.

If we were going to offer discoverablity i think it would need to be a whitelist type model, where open groups request to be added to the official in app discoverablity list. We would then check the group out and decide if they met the content standards, then they could be added. But this then opens up our ability to censor whatever groups we want.

Out of band discovery allows people to create whatever custom list they want with their own moderation standards and we already see a few community run lists like Sessiongroups , SessionDirectory and the LokiLockerList

[ianmacd]

Out of band discovery allows people to create whatever custom list they want with their own moderation standards and we already see a few community run lists like Sessiongroups , SessionDirectory and the LokiLockerList

Is Lokilocker community-run?

Someone told me that you are the owner. Is it not yours? Or maybe you mean that you run it in your own name, not in that of the OPTF.

I have editing rights on that Wiki, but I can't remember how I got them.

[ianmacd]

If we were going to offer discoverablity i think it would need to be a whitelist type model, where open groups request to be added to the official in app discoverablity list. We would then check the group out and decide if they met the content standards, then they could be added. But this then opens up our ability to censor whatever groups we want.

Note that there's no obvious reason to restrict what can be served up in in the desktop client, because there's no gatekeeper that can penalise you by kicking you out of its curated distribution outlet. Session Desktop doesn't rely on a third party for its distribution.

On Android, you could choose the Telegram model: a Play Store client and a Session.org client that differ in the details.

This is easy to do with a centralised service like Telegram. There, only the build version string is different, and on the server side they prevent clients from accessing controversial channels and groups.

Session would need to compile open group discovery out of the Play Store client, or maintain a carefully curated list of allowed groups, but that would indeed open you up to claims of censorship. Better to omit the feature.

Those who want open group discovery on Android would simply have to download the app from the OPTF. That seems like a reasonable and practical compromise, and would drive some people away from the Play Store towards first-party dsitribution. That seems like a bonus to me.

I'm not sure there's an obvious solution for iOS devices.

[KeeJef]

Is Lokilocker community-run?

Someone told me that you are the owner. Is it not yours? Or maybe you mean that you run it in your own name, not in that of the OPTF.

I have editing rights on that Wiki, but I can't remember how I got them.

The Loki locker Gittea instance is run by us, but the repo which hosts that open group list is not run or administered by the team.

[ianmacd]

The Loki locker Gittea instance is run by us, but the repo which hosts that open group list is not run or administered by the team.

Ah, I see.

Thank you for clarifying.

[slrslr]

Understandably, centralized discovery is a censorship liability for Session. Therefore, one can imagine a simple REST API¹ to retrieve a list of communities from a listing provider; all Session would have to do is include the following UI below the community list:

Add more communities from list:
[ Listing provider URL | Add ]

That way, no third-party resources are baked into the app, while remaining open to extension; the resulting communities can be plainly appended to the existing list, or split by provider.

Furthermore, the community list can respond to new additions by way of daily polling and/or an additional button to re-fetch the community lists.

Understandably, this UX isn't beginner-friendly, and still requires guidance from community members. Crucially, however, when given a provider link, users are no longer stuck trying to open community URLs in the browser, as they're natively available in the app.

¹ — Room for such requests may have to be made within Service Nodes.

Default providers

One further step Session can take towards discovery is including default listing providers. The UI may be as follows:

Community lists:

( (S) Official Communities )
( 🇮🇷 Farsi Session Guide | x )

Add communities:

( 🌐 Languages (caliban.org) | + )
( 🖥️ Tech (caliban.org) | + )
( 👤 Zcyph's groups (...) | + )
etc.

( Add from URL ... )

The inclusion of default listing providers is superior to the inclusion of default groups, as curation is delegated to community members managing said listings. One group turned sour in an unofficial listing does not raise corporate eyebrows in quite the same way; no longer would Session need to micro-manage groups based on reputation.

Community members tasked with managing default listing providers are likely to be aware of the need to keep an eye on their listed groups, as well as the security needed to prevent a compromise. Channels to communicate with default listing curators with de-listing periods in case of non-cooperation would ease the resolution of any issues.

[zcyph]

Understandably, centralized discovery is a censorship liability for Session. Therefore, one can imagine a simple REST API¹ to retrieve a list of communities from a listing provider; all Session would have to do is include the following UI below the community list:

Add more communities from list:
[ Listing provider URL | Add ]

That way, no third-party resources are baked into the app, while remaining open to extension; the resulting communities can be plainly appended to the existing list, or split by provider.

Furthermore, the community list can respond to new additions by way of daily polling and/or an additional button to re-fetch the community lists.

Understandably, this UX isn't beginner-friendly, and still requires guidance from community members. Crucially, however, when given a provider link, users are no longer stuck trying to open community URLs in the browser, as they're natively available in the app.

¹ — Room for such requests may have to be made within Service Nodes.

Default providers

One further step Session can take towards discovery is including default listing providers. The UI may be as follows:

Community lists:

( (S) Official Communities )
( 🇮🇷 Farsi Session Guide | x )

Add communities:

( 🌐 Languages (caliban.org) | + )
( 🖥️ Tech (caliban.org) | + )
( 👤 Zcyph's groups (...) | + )
etc.

( Add from URL ... )

The inclusion of default listing providers is superior to the inclusion of default groups, as curation is delegated to community members managing said listings. One group turned sour in an unofficial listing does not raise corporate eyebrows in quite the same way; no longer would Session need to micro-manage groups based on reputation.

Community members tasked with managing default listing providers are likely to be aware of the need to keep an eye on their listed groups, as well as the security needed to prevent a compromise. Channels to communicate with default listing curators with de-listing periods in case of non-cooperation would ease the resolution of any issues.

I like this idea.

Either this, or some other such solution is sorely needed. Simply omitting any discovery mechanism on the grounds of avoiding censorship hurts adoption on multiple fronts because the ordinary users who would be retained by a Telegram style group discovery are lost, but the users who would like options to manually add their own lists are also lost. Some sort of alternative option or middle ground balance needs to be struck.

[zcyph]

You're replying to me, but what you're replying to was a quote from a post by @slrslr (not sure if he'll get notified too)

[ianmacd]

Understandably, centralized discovery is a censorship liability for Session.

I have to stop you right there, because this is two-thirds untrue.

Firstly, the desktop client doesn't rely on any third-party gatekeeper for its distribution, so the question of compliance never arises here. The Session team are free to do as they please.

As far as the Android client is concerned, Google is pacified by offering a crippled binary via the Play Store. A fully enabled binary can still be offered via outside channels. This is how, for example, Telegram deals with an almost identical situation. Rather than handicap their software unnecessarily, they do it only for those users who choose convenience over liberty.

And then there's iOS. Those users have no choice but to remain within the walls of their garden, so a different compromise will need to be sought for them.

[ianmacd]

You're replying to me, but what you're replying to was a quote from a post by @slrslr (not sure if he'll get notified too)

Oops. I've deleted that reply and reposted it in its proper context.

[M1ingithub]

Would some kind of on chain solution help this issue? Perhaps something similar to ONS?

For example operators could make a burn transaction with group ip and name and maybe tags.
Enumerate all groups and drop those that are not active.

[slrslr]

I've previously posted a proposal by other person to solve Community discoverability using so-called "listing providers".

This proposal has since grown. Here is the link to updated proposal: https://codeberg.org/gravel/session-listing-providers