Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone
  1. Home
  2. Categories
  3. Technical Discussion
  4. @julian that is why:

@julian that is why:

Technical Discussion
2 2 3
Log in to reply

Feed RSS
@julian that is why:

Gli ultimi otto messaggi ricevuti dalla Federazione
@pierobosio@soc.bosio.info
Post suggeriti
  • julian@activitypub.spaceundefined

    WP group actor ID URL encoded?

    Technical Discussion wordpress activitypub
    3
    0 Votes
    3 Posts
    0 Views
    julian@activitypub.spaceundefined
    @pfefferle@mastodon.social I'm frankly surprised I ran into a side effect of this so soon after you updated the site :laughing: Either the PR is to be reverted or perhaps WP should handle requests to the URL encoded address :shrug: But after briefing myself on the root cause, it does seem weird that there exist actors with unicode in their ID. Might be if that is the case you should disregard them as non-compliant, who knows. cc @silverpill@mitra.social
  • julian@activitypub.spaceundefined

    FEP-f15d: Context Relocation and Removal

    Technical Discussion activitypub fep threadiverse
    6
    2 Votes
    6 Posts
    9 Views
    julian@activitypub.spaceundefined
    Hi @silverpill@mitra.social right; Move and Remove are explicit actions concerning membership of a context in an audience. Update is overly broad and receivers would have to infer audience change based on what the updated object contains (e.g. Audience Y is suddenly missing, and Z is new, was this always the case?) It is likely that sending audience as an array will not be correctly interpreted by existing software, so this property is an unreliable indicator of context audience membership at best Existing threadiverse apps check addresses, and audience may not be used at all in some. There is no conflict with Move(Person), and I have not heard a convincing reason to adopt a new activity type when these two AS activities work quite well to describe what we want to accomplish.
  • evan@activitypub.spaceundefined

    ActivityPub API Client Reputation

    Technical Discussion
    7
    0 Votes
    7 Posts
    17 Views
    evan@activitypub.spaceundefined
    @thisismissem said in ActivityPub API Client Reputation: > Client reputation isn't really something you can track and share in a decentralized network without introducing some centralisation. I think that some centralisation is fine, as long as admins or even users can choose their reputation data provider. We do this with blocklists for instances already; there's no reason to think that client blocklists would need to be any different. They'd have to have the same caveats; a trusted provider, transparency in the process, etc. > You'd also need moderation tools that can moderate clients in some sort of meaningful way — that's near impossible for dynamic client registration. Agreed. The best I can think of is using the redirect_uri, but that's not really unique -- especially for command-line clients that use localhost! I think the ticket you're working on for moderating OAuth clients for Mastodon is a really big deal. I think it'd be a similar issue for ActivityPub API clients. > That's why we wrote the CIMD spec. Yes! Using the same identifier for clients in a verifiable way is a big help in having a reputation for using on a single server or multiple servers. > But OAuth security and trust models are complex and generally proprietary I think you could get to some pretty useful metrics pretty quickly, though. Some good ones to use might be: How many people on this server (or other servers) have authorized the client What the average rating has been (but you need a way to rate clients!) How many Flag activities have been submitted for this client (you need a way to report clients) Reviews of the client (you need a way to write a review of a client) That data could be local to the server, or could be shared from other trusted servers. A trusted intermediary like IFTAS could be helpful.
  • eyeinthesky@mastodon.socialundefined

    "Critical concept: IRIs are opaque identifiers.

    Technical Discussion activitypub
    1
    0 Votes
    1 Posts
    2 Views
    eyeinthesky@mastodon.socialundefined
    "Critical concept: IRIs are opaque identifiers. You cannot infer meaning from the string pattern — only by dereferencing and inspecting the data." [1] This applies to URIs too. Sadly, almost no #ActivityPub implementations use this principle. Multi-tenant servers and simple account portability (with personal domains) would be relatively easy if they did.🙄 It is what it is.../cc @melvincarvalho [1] https://socialdocs.org/docs/concepts/uris-iris-linked-data/